K60 CAN Broadcast Issue

[norton256]

I have a custom system with 4 K60 MCUs on different PCBs. Unfortunately the routing of the CAN Bus lines was sub-par, and there are some large stubs. That said I would still imagine due to the robust nature of the bus my issue would not occur.

The situation which is arising is that one node sends a command to the other three nodes on the bus. And once in a while one or two of the three K60s on the receive end do not properly act on the command. This occurs more often at temperature extremes.

My problem with this occurrence is that if it were a SI problem, shouldn't the node experiencing the issue corrupt the command on the bus so that none of the nodes receive it properly. Thus forcing the transmitting node to resend it?

[ericfoote1]

Nick, what version of the KSDK are you using?

[norton256]

I'm not using the KSDK. All of the CAN and Clock control code is my own. I am using a header from 2012 which has all of the registers defined in it.

[ericfoote1]

Nick,

Might this be the register you're looking for?

[norton256]

Yes it is. I had found that yesterday, and am currently in the process of implementing it.

[ericfoote1]

Oh, Excellent. Let me know if I can help in any way.

[egoodii]

What is your CAN baud rate?

What is your CAN clock source?

CAN is (ideally) a 'guaranteed delivery' message system, with ACK and NAK at a hardware level to insure that ALL bus receivers get a valid message (within the limits of CRC checking, of course).  And thus, as you say, any 'unhappy receiver' should send a NAK error that will cause ALL receivers to discard, and TX to re-send.  This all relies on EXACT clock timing, though.

[norton256]

I am using the internal osc which the device boots up with. I have tried a range of baud rates: from 1Mb to 5kb.

[egoodii]

Internal osc will NEVER hold the tolerance needed for CAN -- it needs on the order of 0.1% or better so that all devices 'stay in sync' throughout the packet bits.  Internal osc is only 'assured' +/-2% over time&temp (just barely 'good enough' for UART bit extraction).

[norton256]

So after switching over to the RTC driving the FLL in the lowest multiplier setting, I have reliable CAN Comms at both -20C and +50C.

Thanks for the suggestions Earl! I probably would have taken a long time on my own to suspect the clock.

[norton256]

After your last post that is what I was beginning to suspect. Since my external clock source is not present at the time when I need to be using CAN, I need to switch the system to use the RTC which has a 20ppm tolerance. So far I haven't come across the MCG register which switches in the RTC to the FLL.

[egoodii]

That is worth a shot, although I have no tips for you on that clock setup.  I will caution that even 'jitter' is 'something CAN engineers worry about' for bit clocking, and a 'high multiplication loop' will be subject to a fair bit of that.  It all comes down to whether or not 'five bit times later' the CAN receiver can still fix the 'next' transition within the 'synchronization jump width' (where 'no transition run length' is limited in hardware by transition-insertion/removal at a hardware layer) to keep the reception lined up.  Also, at the end, after the last bit of CRC ALL receivers must synchronously transmit up to 8 bits for ACK/NAK in sufficient lock-step so that EVERBODY can 'see and agree'.