CAN BUS communication for MK20DN512VLL10

[kiemvo]

We are developing a motion control board using the below processor

K20DN512VLL10

I have pin 100, 98, 97,72, and 71 connected to a CAN transceiver (CAN address pin 0 - 4).  I also have pin 99, 42, and 43 connected to CAN transceiver (CAN_speed, CAN_TX, and CAN_RX).  There is also a DIP switch to set the CAN address.  Do you have any sample code for CAN communication on this chip?  What SDK is the best for this kind of development?  Thank you very much.

[egoodii]

CAN is quite intolerant of comunication link parameter variations.  I assume these 'slave nodes' are 'known to work' in the speed of interest.  Do you see these slave(s) attempt to TX anything [strobes on their TX pin(s)] at the end of these Kinetis-sent packets?

What is the 'ultimate' clock source for your Kinetis CAN peripheral?

[kiemvo]

Hello Earl,

The nodes are able to send message to each other, but the whole bus can only work if we use CANUSB  to open the bus first.  Can we do that directly on the firmware?  Can a node or any node on the bus open the bus?  Thank you very much. 

[egoodii]

CAN is a fully-distributed-multimaster interconnect.  The is no such concept as 'open the bus'.  There is either 'two-or-more nodes for a send-and-acknowledge', or there is 'the case where a master fails to get an ACK to a message and continuously re-tries it'.  I can only assume you mean 'Open' on controls for a Lawicel CANUSB dongle to bring IT 'online' from your PC --- and if THAT is 'necessary' to see any proper communication, I have to assume IT is the only viable slave to return an ACK and let each message complete.

[kiemvo]

Thanks for your response, Earl.  My connection is exactly the at the below image 1.  We start the communication by setting the rate to 500kbps and then 'Open'.  After we 'Open' then we can start sending frame from the CANUSB to the node, and we can also send from the node back to the USB.  If I don't use the CANUSB then the connection is similar to image 2.  The bus is a 4-wire telephone cable (CAN-H, CAN-L, GND, GND).  With the second setup, node 1 cannot send to node 2 (no firmware change).  If I disconnect the USB connector (image 1), node 1 cannot send to node 2.  I suspect that the firmware miss the CAN initialization step.  Any idea about this?  

[egoodii]

So you're saying that in 'setup 1' all three nodes can freely send & receive messages among each other, but without CANUSB no communication completes --- the only explanation for that would be that you have some setting in each NODE interface that prevents it from sending any kind of proper 'acknowledge' add-on at the end of a received packet (back to the sender), such that only CANUSB is supplying that necessary feedback.

[kiemvo]

But I still don't get it why Node 1 can respond to CANUSB when it received the message from CANUSB.  It means that it is able to send a proper ACK back to the CANUSB.  Let's say in setup 1, if node 1 sends a message to 2 and node 2 receives that message.  Node 2 set the ACK properly to terminate the transaction, not the CANUSB.  It is not the CANUSB to set that ACK bit, so why removing CANUSB terminates the sending capability. 

[egoodii]

CAN is inherently a 'broadcast' protocol, with guaranteed delivery.  In a properly configured system ALL slaves respond to ALL messages at the 'bus' layer (but can be filtered by higher-layers).  For a 'good' transfer, ALL slaves will return ACK.   That being said, 'message delivered' requires that 'at least' one slave return ACK, and NO slave return NAK (lest all receivers discard the message, with MASTER to send a retry).  So CANUSB can indeed supply an ACK for all messages from any other TX.  You might look to see if you have loopback(LPB) or 'listen only'(LOM) in your nodes --- these will prevent normal ACK generation.

You might also try all these functional experiments at a MUCH lower speed, and 'work up' to your full speed.  The fully distributed arbitration and semi-synchronous reception and response-slot-allocation require some pretty tough physical requirements, all of which are eased at a slower speed.  If you need to go faster than 125K, there are no shortcuts --- you must fully understand the bit timing elements and external propagation delays with bus-length limits.

I had asked previously what your ultimate CAN-peripheral clock source is in each node --- I still think that would be important to know here!

[kiemvo]

Thank you very much for all your advice.  The problem was at the cable that we used.  That cable has twisted wire.  Problem solved. 

[mjbcswitzerland]

Hi

I use the Total Phase Komodo CAN DUO for my work with CAN. It can be set to active or passive mode.
When in passive mode it just observes the bus. When in active mode it observes and also ACKs as other nodes do.

If there is only one node on the bus apart from the analyser, that node will be able to send messages without errors as long as the analyser is in active mode (because it acknowledges the messages, even if it is not a normal member of the network). If the analyser is in passive/listening mode the node cannot send any messages without errors being reported.

Therefore I conclude that the behavior is probably normal if there is one active node (plus an active analyser). It wouldn't be normal if there were more than 1 active node since it means that second active node is not correctly ACKing.

Regards

Mark