View previous topic :: View next topic |
Author |
Message |
newguy
Joined: 24 Jun 2004 Posts: 1909
|
OT: CAN bus clock drift question |
Posted: Wed Sep 15, 2010 4:35 pm |
|
|
Sorry for this off topic question, but I know that there are many individuals here with a lot of collective CAN experience....
Does anyone know what the effect would be of a device on a CAN bus having its clock drift far out of spec? Obviously there would be CAN errors but is it possible to lock up the bus entirely so that nothing can transmit? |
|
|
andrewg
Joined: 17 Aug 2005 Posts: 316 Location: Perth, Western Australia
|
|
Posted: Wed Sep 15, 2010 7:53 pm |
|
|
Short answer: Yes.
The PIC CAN hardware will continually transmit until acknowledged by at least one other node (which implies the baud rate must be correct), or you implement a timeout and abort the transmission.
Higher priority messages should still be able to get out. _________________ Andrew |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1909
|
|
Posted: Thu Sep 16, 2010 7:08 am |
|
|
That's pretty much what I figured....
....I inherited a [censored] project that had a litany of issues, both h/w and s/w. Two different processor families in the product (multiple instances of each) with each family running at very slightly different CAN bit rates. [I know, I know, but there's nothing I can do about it given the architectures and crystals.] To compound things, one family runs very very hot, and these issues only pop up when it's really really hot and (to make my life really difficult), only infrequently. In other words, I can't reproduce in the lab the issues seen in the field.
I've found and fixed many h/w and s/w issues but the CAN lockup still happens every now and again. I've confirmed that the components that get very hot are to blame. I've ruled out s/w bugs and keep coming back to temperature induced clock drift.
Thanks for confirming what I suspected. |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1909
|
|
Posted: Thu Sep 16, 2010 8:01 pm |
|
|
Update: It was indeed clock drift induced by temperature swings. I was able to slightly alter the CAN divisors of the hot environment device so that its nominal frequency was very slightly below the other family's rate (it was above before). I even managed to luck out and find a set of values that results in a smaller nominal % error than the original value.
Anyway, prior to the clock s/w alteration, a heat gun was able to induce the CAN error behaviour seen in the field. After the update, I couldn't get it to fail.
Thanks for the help. |
|
|
|