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
pictures of CAN communication?
Started by ●April 24, 2006
Reply by ●April 24, 20062006-04-24
Mike Noone <mnoone.uiuc.edu@127.0.0.1> wrote:> 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!Then images won't do you any good. There's really no way you can expect to successfully debug what you don't understand.> 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).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 by ●April 24, 20062006-04-24
On Mon, 24 Apr 2006 06:46:51 +0000, Mike Noone wrote:> 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!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 by ●April 24, 20062006-04-24
Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote in news:4b3gqjFvq585U2@news.dfncis.de:> Mike Noone <mnoone.uiuc.edu@127.0.0.1> wrote: >> 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! > > Then images won't do you any good. There's really no way you can > expect to successfully debug what you don't understand. > >> 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). > > 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.... ... 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 by ●April 24, 20062006-04-24
Dave <dave@comteck.com> wrote in news:pan.2006.04.24.10.46.29.266770@comteck.com:> On Mon, 24 Apr 2006 06:46:51 +0000, Mike Noone wrote: > >> 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! > > 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~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: https://netfiles.uiuc.edu/mnoone/www/CAN%20oddness.jpg 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 by ●April 24, 20062006-04-24
On 2006-04-24, Mike Noone <mnoone.uiuc.edu@127.0.0.1> wrote:> 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 signalsYou're worried about the voltages? What sort of transceivers are you using?> 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'm looking at the MCP2515 datasheet and there are diagrams showing exactly what frames contain on pages 9 through 13.> I mean I'm fully familiar with what bits should be where and > all of that,Well then, you know what the signals should look like: A 1 bit is 5V, and a 0 bit is 0V.> 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: > > https://netfiles.uiuc.edu/mnoone/www/CAN%20oddness.jpg > > 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)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 visi.com PRUNE WHIP!!
Reply by ●April 24, 20062006-04-24
Mike Noone <mnoone.uiuc.edu@127.0.0.1> wrote:> length, etc. But they make no mention of what the signal should actually > look like.That's because there's basically nothing to mention: CANTX sends, CANRX receives, at ordinary levels for digital I/O pins.> https://netfiles.uiuc.edu/mnoone/www/CAN%20oddness.jpg> Does that look like anything I should recognize?No.> If it matters, the devices are only about 20cm away from each other > and I'm not using terminating resistors.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 by ●April 24, 20062006-04-24
Grant Edwards <grante@visi.com> wrote in news:124pqnh5d84r180 @corp.supernews.com:> On 2006-04-24, Mike Noone <mnoone.uiuc.edu@127.0.0.1> wrote: > >> 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 > > You're worried about the voltages? What sort of transceivers > are you using?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...>> 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'm looking at the MCP2515 datasheet and there are diagrams > showing exactly what frames contain on pages 9 through 13.Right - and that's what I was expecting to see>> I mean I'm fully familiar with what bits should be where and >> all of that, > > Well then, you know what the signals should look like: A 1 bit > is 5V, and a 0 bit is 0V. > >> 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: >> >> https://netfiles.uiuc.edu/mnoone/www/CAN%20oddness.jpg >> >> 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) > > 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.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 by ●April 24, 20062006-04-24
Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote in news:4b48dqFvsvpuU1@news.dfncis.de:> Mike Noone <mnoone.uiuc.edu@127.0.0.1> wrote: > > >> length, etc. But they make no mention of what the signal should >> actually look like. > > That's because there's basically nothing to mention: CANTX sends, > CANRX receives, at ordinary levels for digital I/O pins.That's what I had thought - but the data I was getting just wasn't make any sense at all.> >> https://netfiles.uiuc.edu/mnoone/www/CAN%20oddness.jpg > >> Does that look like anything I should recognize? > > No. > >> If it matters, the devices are only about 20cm away from each other >> and I'm not using terminating resistors. > > 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.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 by ●April 24, 20062006-04-24
>> 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. > > ... > > ... > > 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. > > -MikeYeah, that did seem pretty far out of line... ~~ Mark Moulding "I prefer heaven for climate, hell for company."