pictures of CAN communication?

Hi - I am working on debugging a CAN bus. Problem is, I've never used CAN before, so I don't even know what correct communication should look like! Does anybody have images of what the data on the CANTX and CANRX lines should look like (the lines between a CAN controller and a CAN transciever). Thanks!

-Mike

Reply to
Mike Noone
Loading thread data ...

Then images won't do you any good. There's really no way you can expect to successfully debug what you don't understand.

They should be moving --- with no long stretches of no movement inside a message. What exactly "long stretches" are, and how they'll move, depends on what the CAN controller is doing.

If you can't find out what should be happening from the CAN message you're trying to send, and the CAN specs, then with all due respect, I'll have to advise you to get help, since you're quite obviously not able to do this job yourself.

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

Google "Controller Area Network" and there is lots of info. The Kvaser, Algonet, and Bosch pages would be good starting points. On the Kvaser page, select the "Protocol Tour" then "CAN O'scope pics" and you will see scope images of CAN transmissions taken on the bus. I've never had a problem with a transceiver unless it was turned off, which should be easily discernible.

I think all three pages show diagrams of the various messages and have CAN descriptions.

One comment: you cannot debug a CAN node in isolation--you need another node to ACK transmissions. All of the CAN testers I've used have had this feature. Kvaser has a pic showing what happens when a message is not ACKed. And even an ACK doesn't mean that the intended receipient got the message.

~Dave~

Reply to
Dave

Hans-Bernhard Broeker wrote in news: snipped-for-privacy@news.dfncis.de:

...

...

Wow. Do you make a point to go out of your way to insult all strangers, or are your panties just caught in a twist today? Way to make (incorrect) assumptions. Please never respond to one of my posts again, as it's quite obvious you're more interested in a fight than in actually being helpful.

-Mike

Reply to
Mike Noone

Dave wrote in news: snipped-for-privacy@comteck.com:

Hi Dave - thanks alot for the response. I looked at the Kvaser page, but the pictures are all of the CANH and CANL signals. I was a little worried about the voltages on these signals so I thought it'd be easier to debug looking at the CANTX and CANRX signals. It's the oddest thing - in the datasheets for the CAN devices that I'm using (Atmel AT91SAM7X256 and Microchip MCP2515) they talk all about the protocol, speed, bit length, etc. But they make no mention of what the signal should actually look like. I mean I'm fully familiar with what bits should be where and all of that, but it doesn't match up *at all* with what I'm seeing. I've configured the Atmel chip to send and only send, and the Microchip to receive and only receive. This is the beginning of the signal:

formatting link

Does that look like anything I should recognize? If it matters, the devices are only about 20cm away from each other and I'm not using terminating resistors. (I didn't think they'd be necessary when the transmission lines were so short, though it'd be easy enough to add them in if needed)

-Mike

Reply to
Mike Noone

You're worried about the voltages? What sort of transceivers are you using?

I'm looking at the MCP2515 datasheet and there are diagrams showing exactly what frames contain on pages 9 through 13.

Well then, you know what the signals should look like: A 1 bit is 5V, and a 0 bit is 0V.

You _have_ to have terminating resistors. They're not just there for supressing reflections. CAN trasceivers only drive in one direction and rely on the terminating resistors to return the bus to the "idle" state.

--
Grant Edwards                   grante             Yow!  FIRST, I'm covering
                                  at               you with OLIVE OIL and
 Click to see the full signature
Reply to
Grant Edwards

That's because there's basically nothing to mention: CANTX sends, CANRX receives, at ordinary levels for digital I/O pins.

No.

It absolutely does matter, and you got it wrong. Which is exactly why you see the above: the transmitting CAN controller discovers almost immediately that they can't get the differential CAN bus working (RX doesn't follow TX, i.e. the echo is wrong), so it gives up. I guess the 50 us regular pattern you see is the CAN controller re-trying to send the message.

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

Grant Edwards wrote in news:124pqnh5d84r180 @corp.supernews.com:

I'm using a TI SN65HVD231. I simply didn't know the max voltage my logic analyzer could handle, and I didn't exactly feel like risking an $11K machine...

Right - and that's what I was expecting to see

OK, I'll add them in. It's odd, most of the CAN boards I look at have a jumper to enable/disable the terminating resistor. Thus I assumed it was only needed when dealing with long transmission lines.

When don't you need a terminating resistor?

Thanks!

-Mike

Reply to
Mike Noone

Hans-Bernhard Broeker wrote in news: snipped-for-privacy@news.dfncis.de:

That's what I had thought - but the data I was getting just wasn't make any sense at all.

Your explanation of the 50us pattern makes perfect sense. That was completely the wrong frequency (it should be running at 500Khz) thus I was really confused. I expect you can understand my initial question and confusion now.

-Mike

Reply to
Mike Noone

Yeah, that did seem pretty far out of line... ~~ Mark Moulding "I prefer heaven for climate, hell for company."

Reply to
Mark Moulding
[snip]

You termination at each end of the line but not in the middle. So each line of the bus should have exactly two resistors, one at each end. Intermediate nodes don't need them and shouldn't have them.

Peter

Reply to
Peter Dickerson

You always need the terminating resistors in a CAN network, not in

*individual* nodes. Normally they would be installed in the two nodes that are farther apart, at opposite ends of a network segment.
Reply to
Roberto Waltman

Um, OK, but the max CANH and CANL voltages are the same as the max CANTX and CANRX voltages.

My bad, you're using 3.3V parts not 5V parts.

That's because you generally want one terminating resistor at each end of the bus. If you've got 15 devices on the bus, you only want to enabled the terminating resistors on the 2 "end" devices. If you left the terminating resistors enabled on all

15 devices, the DC impedance of the bus would be too low to drive reliably.

Nope.

It would help a lot if you spent a few minutes reading about how CAN works. You're using an ISO 11898-2 physical layer, so pay attention to stuff about that implimentation:

formatting link
formatting link
formatting link

Quoting from that last page:

Bus Termination

An ISO 11898 CAN bus must be terminated. This is done using a resistor of 120 Ohms in each end of the bus. The termination serves two purposes:

  1. Remove the signal reflections at the end of the bus. 2. Ensure the bus gets correct DC levels.

An ISO 11898 CAN bus must always be terminated regardless of its speed. I'll repeat this: an ISO 11898 CAN bus must always be terminated regardless of its speed. For laboratory work just one terminator might be enough. If your CAN bus works even though you haven't put any terminators on it, you are just lucky.

You never don't need a terminating resistor.

In the real world, you need one terminating resistor on each end of the bus. For short buses (e.g. on a bench), you can usually get by with just one resistor anywhere on the bus.

--
Grant Edwards                   grante             Yow!  If I pull this SWITCH
                                  at               I'll be RITA HAYWORTH!! Or
 Click to see the full signature
Reply to
Grant Edwards

Roberto Waltman wrote in news: snipped-for-privacy@4ax.com:

Ohh boy. Now I'm wishing I had previously read up on CAN a bit more than I did. I thoguht I had read everything I needed to know - but obviously not! From what you and Peter are saying - normally a CAN bus is just one long pair of wires with nodes along the way, and then resistors at the two ends. The way I designed it on my system, I have one primary board using an AT91SAM7X256, and then there are 6 connectors on this board, going to 6 different CAN devices. So each connector has +6V, +3.3V, GND, CANH, and CANL on it. Each CAN device is about 10cm away from the connector. Is there a good solution for this, while maintaining the individual connectors? Would it work for me to just add a resistor on the AT91SAM7X256 board, and then add a resistor on one of the 6 other boards? Alternatively, I could pull the CAN wires from the connectors and just run one long wire that goes between all 6 nodes and then to the main board. Then, it would be a clear call where I'd put the other terminating resistor. Would that be best?

Thanks,

-Mike

Reply to
Mike Noone

No.

Yes, assuming that your controller is one end of the bus (usual case). The terminating resistors should be on the end nodes of the bus.

Steve

formatting link

Reply to
Steve at fivetrees

Correct. The nodes can be connected to the main trunk with stubs of no more than few inches, so what you describe below will most likely work.

This will probably be better. In a system I was involved with some time ago, the CAN bus connecting several devices was an (open) loop, beginning and ending in the same board, with nodes "hanging" from it at different locations.

Remember that the purpose of the termination Rs is not just to provide the correct impedance to avoid reflections, etc. as it seems you believed originally. Their main function is to "pull" the voltage in the CANH/L lines together when no node is driving them.

The "dominant" state is CANH driven high, (obviously) CANL driven low. The "recessive" level is both lines at the same voltage, via the terminating resistors and all drivers in high-Z condition.

Now going back to your setup, it may work as is, if you put a termination resistor (1/2 the value) in the main board only. (it may be necessary to experiment with different bit rates) but you may run into trouble if you need in the future to add more nodes farther away than the current ones.

Reply to
Roberto Waltman

I think someone suggested as much earlier in the thread.

ends.

there

It seems that you have created a CAN star rather than a CAN bus. With only

10 cm per node you have a fair chance that it will work with a single 1/2 value resistor (or two std resistors on the two longest lengths) providing you don't go to fast.

goes

Best, but it's work trying the star first if changing the plumbing is a big hassle.

Peter

Reply to
Peter Dickerson

Allright I'm posting from the lab where we don't have usenet access, so bear with me as I have to use google groups.

I looked through the resistors I have on hand and they're most very large (in the Ks) so my choices were limited. I found a stash of 80.6 ohms that I use with LEDs, so I tried putting one of those on the AT91SAM7X256 board. It seems to work a whole lot better, though I'm still getting odd results that I do not understand. Here's a screen from my logic analyzer:

formatting link

it repeats that message forever. If you notice the M1 to M2 length, it seems to nearly match with the expected 500Khz frequency (1/2.086252E-6 = 479.3Khz). I believe this is due to an aproximation I had to do due to the odd frequency the AT91 chip is running at. The other chips should be running at exactly 500Khz. Could that be causing the problem? By the way, the message I'm *trying* to send is a standard data frame with identifier = 1 and 8 data bytes = 0xAAAAAAAA55555555. The message that appears to be being sent is

000001000001011100000100000100000100000100000111101000100100 followed by 29 1s.

Can anybody make any sense of this?

-Mike

Grant Edwards wrote:

Reply to
Mike Noone

Your baud rates mismatch by 4%? If your baud rates really do mismatch by 4%, I don't think it's going to work.

What problem?

You need to spend some time reading up on how CAN bus works instead of trying random shit and posting the resulting waveform to Usenet to see if anybody can make any sense of it for you.

--
Grant Edwards                   grante             Yow!  Are you guys lined up
                                  at               for the METHADONE PROGRAM
 Click to see the full signature
Reply to
Grant Edwards

Break out your scope and look at the CAN bus. The Kvaser pics show busses with incorrect/no termination and their effects. It looks like your CAN controller is not recognizing the received bits correctly and is attempting error recovery--it does this when the "error" is recognized rather than attempting to complete transmission.

~Dave~

Reply to
Dave

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.