8
\$\begingroup\$

I am using a 16-bit MCU, PIC24HJ64GP504, to write a CAN based application. Basically it is communication between my board and one another node which continuously keeps on sending data to my board using CAN at 1 Mbit/s. I am configuring the ECAN module in my PIC24 to work at 1 Mbit/s. I have written the code in such a way that for the first 10 ms the ECAN module will accept all messages coming in from the other side, and after that I have re-configured the ECAN module to accept only those messages with message ID 0x13.

Now here comes the issue.. The other node and my board are powered up at the same instant. The other node starts transmitting messages after 40 ms or so after powerup. But I am not able to get any message from it on my board. Now if I power up my board first, give it some time to reconfigure the ECAN module with new filters and settle down and then power up the other node, then everything works perfectly.

Now the strangest part.. If I have a CAN bus analyzer connected between my board and the other node and even if I power up both the nodes at the same time, everything works fine...no need to power up my board first. I have tried this with three different bus analyzers from different manufacturers and got the same results.

To me it appears that during re-configuration of the ECAN module, it takes some time to settle down. And with the introduction of the bus analyzer in the bus, this time is somehow cut short so that everything works perfectly. But I am not sure what exactly the problem might be.

I have been struggling with this issue for the past seven days.

PS: Today I checked with a scope and found out that if the other node starts transmitting after 170 ms after powerup, then the whole thing works fine. Before that, my device won't receive any messages from it unless the bus analyzer is connected. The worst part is I can't delay the transmission of the other node, the firmware of that node is proprietary.

Also I read in a forum today that CAN needs the 120 Ω resistor at the node to make it working (even though my node does not have one and it works fine, provided given some time to settle after reconfiguration). I suspect the introduction of the bus analyzer somehow changes some network's electrical parameters such that the time taken by my node to settle after reconfiguration is cut short. But I am not sure.. :(

\$\endgroup\$
  • 1
    \$\begingroup\$ Can you give us links to all of the products you are using. This allows concrete answers to be more easily formulated. \$\endgroup\$ – Kortuk Mar 15 '12 at 16:01
  • \$\begingroup\$ Are you able to make changes to your board, or are you expecting/hoping for a purely software solution? \$\endgroup\$ – vicatcu Mar 15 '12 at 16:54
  • \$\begingroup\$ Are you sure the other node keeps transmitting, even if your own node is not up and running? Some CAN implementations use an error counter, and if this overflows (for example due to no nodes receiving), the transmitting node stops. \$\endgroup\$ – Schedler Mar 16 '12 at 14:34
  • 1
    \$\begingroup\$ keil.com/download/files/can_primer_2009sp.pdf Excellent primer in CAN. \$\endgroup\$ – Stephen Collings May 16 '12 at 18:16
9
\$\begingroup\$

You "read on a forum" somewhere that the CAN bus needs resistors? Seriously!!?

This is a integral part of your design. If you are going to use CAN, you need to understand it, which means reading the relevant documentation.

Spearson is right but for the wrong reason. A differential CAN bus as you likely have (you didn't say what interface chip you are using, but probably you have a standard differential CAN bus as driven by something like a MCP2551 at each node) requires a resistance between the lines. This is because the recessive state is signalled by the two lines passively pulled together, and the dominant state by them being actively pulled apart. The resistors between the lines in that sense are the equivalent of a pullup resistor on a open collector line. Without something pulling the lines together when nothing is driving the bus, the bus doesn't work.

The resistors also function as terminators as spearson pointed out. You generally use twisted pair for the two bus lines. This has a impedance of around 120 Ω. This type of differential CAN bus is defined to have 60 Ω between the lines as a pull-together so that it can be implemented with 120 Ω at each to terminate the bus and avoid reflections.

 

\$\endgroup\$
  • \$\begingroup\$ What does "spearson" refer to? A user named "spearson" that left a comment (since then deleted or the user changed screen name?)? A book (name of author)? \$\endgroup\$ – Peter Mortensen Nov 10 '15 at 19:12
  • \$\begingroup\$ @peter: Apparently yes. \$\endgroup\$ – Olin Lathrop Nov 10 '15 at 20:33
4
\$\begingroup\$

In normal CAN operation, a node will repeat its transmission until it is ACK'd or the error count has been exceeded. When you have the CAN analyzer connected to the network, it will issue the ACK bit when it detects the frame from your first node, making the transmission successful. If you are using the Microchip CAN BUS Analyzer you can configure it to 'listen-only' mode, which means it will not issue any ACK bits, therefore not affecting the network. So you should be able to see the repeated CAN frame in the analyzer display until the second node issues an ACK or the first node quits transmitting due to error count.

The ACK bit will be set by a receiving node (if the frame is complete and correct) regardless of any address filtering.

Most likely your first node is reaching an error state due to the frame not being ACK'd. You should detect this in software using the CiINTF register. You can also configure the PIC to issue interrupts for error conditions using the CiINTE register.

If your scope doesn't decode CAN frames, try the Saleae Logic analyzer. It will decode the CAN frame and show the ACK/Error bit. It has been much more reliable than the Microchip CAN analyzer.

\$\endgroup\$
3
\$\begingroup\$

There is an ACK slot (two bits) in a CAN Frame. If a node A is transmitting the data and there are five others nodes on bus, after transmission whichever node receives the frame will put the dominant bit in the ACK slot. This indicates the message was transmitted successfully. Otherwise CAN controllers consider it as an error on the bus.

When you add a CAN analyzer, it sends ACK to the transmitter. The transmitter thinks the bus is good and keeps on transmitting. In the absense of a CAN analyzer, when you re-configure your CAN controller, the transmitter doesn't get an ACK and thinks there is an error on the bus, so it stops transmitting.

I hope you got the point.

Make sure that ACK is getting properly. Also try not to turn off your CAN receiver completely while doing re-configuration.

Another trick (I am not sure it will work always) is to send a zero DLC and zero ID frame after re-configuration. This will tell the transmitter node that the bus is active, and it will start transmitting.

Note: a 120 Ω resistor is a MUST!!!. A terminating resistance is THE important thing on ANY bus.

\$\endgroup\$
  • \$\begingroup\$ Your trick of sending a zero DLC and zero ID frame after initialisation, is actually already in the standards, known as a bootup message. Its ID is the same as the heartbeat (0x700 + node ID) and has a single DLC of 1. Analyser tools should recognise this. \$\endgroup\$ – BullBoyShoes Jul 18 '12 at 20:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.