Kinetis MicrocontrollersのトピックRe: K60 CAN Broadcast Issue

K60 CAN Broadcast Issue

norton256 — Tue, 05 Jul 2016 15:28:49 GMT

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?

Re: K60 CAN Broadcast Issue

egoodii — Tue, 05 Jul 2016 17:19:44 GMT

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.

Re: K60 CAN Broadcast Issue

norton256 — Tue, 05 Jul 2016 17:25:36 GMT

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

Re: K60 CAN Broadcast Issue

egoodii — Tue, 05 Jul 2016 18:15:40 GMT

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).

Re: K60 CAN Broadcast Issue

norton256 — Tue, 05 Jul 2016 18:24:12 GMT

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.

Re: K60 CAN Broadcast Issue

egoodii — Tue, 05 Jul 2016 18:32:33 GMT

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'.

Re: K60 CAN Broadcast Issue

ericfoote1 — Wed, 06 Jul 2016 14:44:06 GMT

Nick, what version of the KSDK are you using?

Re: K60 CAN Broadcast Issue

norton256 — Wed, 06 Jul 2016 14:59:34 GMT

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.

Re: K60 CAN Broadcast Issue

ericfoote1 — Wed, 06 Jul 2016 15:46:40 GMT

Nick,

Might this be the register you're looking for?

Re: K60 CAN Broadcast Issue

norton256 — Wed, 06 Jul 2016 16:06:55 GMT

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

Re: K60 CAN Broadcast Issue

ericfoote1 — Wed, 06 Jul 2016 16:11:05 GMT

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

Re: K60 CAN Broadcast Issue

norton256 — Mon, 11 Jul 2016 20:01:58 GMT

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.