K60 CAN Broadcast Issue

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

K60 CAN Broadcast Issue

1,459 Views
norton256
Contributor III

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?

Labels (1)
Tags (1)
11 Replies

1,080 Views
ericfoote1
NXP Employee
NXP Employee

Nick, what version of the KSDK are you using?

0 Kudos

1,080 Views
norton256
Contributor III

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.

0 Kudos

1,080 Views
ericfoote1
NXP Employee
NXP Employee

Nick,

Might this be the register you're looking for?

pastedImage_1.png

pastedImage_0.png

0 Kudos

1,080 Views
norton256
Contributor III

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

0 Kudos

1,080 Views
ericfoote1
NXP Employee
NXP Employee

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

0 Kudos

1,080 Views
egoodii
Senior Contributor III

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.

0 Kudos

1,080 Views
norton256
Contributor III

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

0 Kudos

1,080 Views
egoodii
Senior Contributor III

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

1,080 Views
norton256
Contributor III

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.

0 Kudos

1,080 Views
norton256
Contributor III

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.

0 Kudos

1,080 Views
egoodii
Senior Contributor III

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