CAN problems, part II

And as a quick update, I just looked at the output from the CAN transciever on the Microchip board (I've only been looking at the data coming out of the Atmel board) and the CANTX line is just high, while the CANRX line looks perfect. So, this means it's a hardware problem, right? And being that the other lines are OK, and I've made sure my wires connect and everything, it's probabaly the transciever, correct?

Sorry, I have exactly 0 experience debugging CAN.

-- and the fact that you were messing with the termination when it was running. Beep out your CANH line before you change transceivers -- you may have shorted something.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

It wasn't intentional! I've been up for a very very long time. Heading to bed after I post this.

What do you mean "beep out"?

On a side note - the output from the Atmel chip I believe is perfect - I've compared it with a standard data frame and all the bits seem to be in the right place. Took me a little while to figure out that the extra little blips were the bit stuffing - but after doing some more reading on what "nrz encoding with bit stuffing" means I realized that those blips were to be expected!

Problem is the Atmel chip keeps on sending this seemingly correct standard data frame, over and over, even though I only request transmission once. If there were a problem with the can transcievers, could this be a valid symptop? The Microchip part also never seems to see the frame, though admittedly I could have the part setup incorrectly.

So to recap:

-output from Atmel chip looks good, but frame is sent repeatedly

-both can lines between Atmel chip and transciever look good

-one can line between the two transcievers looks good, while the other doesn't

-one can between the transciever and the mcp2515 looks good, while the other doesn't

Time to get some sleep - I'm pretty sure I'm going to pass out within the next 5 minutes.

-Mike

Tim Wescott wrote:

Beep, buzz, Ohm. Use you multi meter to check for shorts or opens. Power off this time.

Remember the the sender will keep transmitting until it gets and ACK. Bad bus, no Ack.

Note that if a message is not successfully received by another node it will be retransmitted continuously. If only a single node is operating, this is what you will see.

Do you have a PC based CAN analysis tool? Having a known good implementation can make development run much more smoothly.

Andy

Not really. This is more likely a software problem. E.g. if the CAN controller of that Microchip board has not been activated by the software, it has no reason to send anything, so its CANTX pin will not change state. An active CAN controller would do *something* on receiving a frame: either send an ACK, or raise an error flag. If it does nothing at all, that means it's at least error-passive, possibly bus-off.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

You've overlooked one. The ACK bit should differ between TX and RX. This is the one bit in a CAN frame that should _not_ echo exactly. If it does, the CAN node will assume it's not connected to a working bus, and retransmit until that changes.

Open CAN spec, see the secton on error handling and containment.

Yes. But it could also signify other things.

E.g. if you accidentally tied your CANH line to VCC or GND, you might see surprising things.

Earlier on you said the frame arrived at the CANRX of that part. So, which is it?

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Hi Andy - thanks for the response. So as long as there are two normally operating nodes on a CAN bus, a message will only be sent once, right? Or does it continuously send until it reaches a mailbox with the proper id?

I don't have any sort of CAN analysis tool. I was actually thinking about making my own once I get this all working, as I can definitely see the use for one!

-Mike

Mike: I don't want to be confrontational, but this question shows again that you lack a basic knowledge of how the CAN protocol works.

I do not know what your project is for, under what type of pressure to deliver you may or may not be, etc, but as others already pointed out, it seems that the most beneficial course of action for you will be to turn off all your equipment and spend at couple of days studying the CAN specs. You will recover this time later on, several times over.

The message is retransmitted until at least _one_ node ACKs the message. Whether or not it is actually received into a mailbox is a whole different problem. All normally functioning nodes will ACK if they see a valid transmission, even if none of them receive the message into a mailbox.

~Dave~

I thought I should update:

I got in some more parts today so I was able to setup two identical boards using the MCP2515 chip. It was surprisingly easy to get communication working between these two boards. That also showed that there were no hardware problems on them. While doing that - I discovered two typos in my code for the MCP2515 chips - one was putting the chip in the wrong mode, though I don't believe it was affecting anything. The other was much more important - it was setting the number of TQ/bit to a total of 9, whereas the Atmel chip was set to 10. I spotted this by noticing that the bits coming out of the MCP2515 were

1.8us long, instead of 2us as I had expected. After making these changes, the Atmel chip was able to communicate with the MCP2515 parts.

There are still a couple kinks to work out, but everything is working, thank goodness! No hardware problems whatsoever.

Thanks again to everybody that helped me through this problem, and thanks for being patient with my inexperience with this topic.

-Mike Noone

Hans-Bernhard Broeker wrote:

If there are no ACKs, then most (all ?) CAN controllers will go into some sort of error mode, and stop transmitting. One usually the have to go through a specific sequence of events to get the controller out of error mode, so that it will try to transmit on the CAN bus again. This makes it quite difficult to check if one is getting anywhere without having a working node on the bus that can ACK a message.

Regards Anton Erasmus

What kind of time frame are you talking about, hours, weeks or years ?

While most controllers go to some sort of BUS-OFF state, this usually requires a large number of true faults during the transmission in a _healthy_ bus.

However, if there is no other node doing the Ack, the transmitting node will try to transmit forever (at least more than a few minutes according to my observations :-).

Yes, you definitively need at least one functional node on the bus.

Paul

The CAN controllers I have used goes to an error state in milli-seconds if transmissions are not ACKed. Typically the transmission is re-tried 255 times, and then the node goes to a BUSOFF error state.

My experience is that it happens much faster than this. I am not sure whether this is specified in the CANBus spec or not.

I think this is what trips up many people when they first try to use CAN Bus. It is natural to write transmit code and then to look with a scope if one see anything on the BUS. However if the controller goes into fault mode, then it stops trasnmitting and one does not see anything.

Regards Anton Erasmus

While the controller may go into a BUSOFF state, thus preventing any further frames to be sent, this does not necessary terminate the transmission of the _active_ frame, which may be transmitted repeatedly until Acked. In control applications this can cause problems, since once the cable is reconnected, a severely delayed frame might cause unwanted control actions, such as starting a machine. To avoid such situations, e.g. regular heartbeats should be present before accepting any new commands.

Paul