CAN messages looks strange ?

[Spekkio]

I have some problems getting AN930 to work with PIC18F25K80. I have been writing on the microchip forums, but there doesn't seem to be much activity there.

Anyway, I took a look at how the CAN messages look with an oscilloscope, and I think they look strange.

I cannot figure out what the problem is. I have been using CAN before, and I cannot remember that it looked liked this. The probe is calibrated, and the signal that
goes into the MCU on the recieving side looks OK, so the transceiver seems to convert the signal OK.

I forgot to name which one was CANH and CANL though :/




This is how the tranceiver converts this signal, this is not the sending side, this is the recieving side.



Is CAN supposed to look like that? I think it looks strange.

[Psi]

It looks to me like you're measuring the signal without a ground path.

I dont know much about CAN, is it isolated? maybe your probe ground is on the wrong side.

[Spekkio]

It looks to me like you're measuring a signal without a ground connection.

Hmm. All the units on the bus share the same GND, the connection seem to be fine. I'm not sure yet if there is any problem with the wire on the probe though.

I have a cable with 4 wires. 2 twisted pairs.

CANH and CANL is in a pair, and +3.3V and GND is in a pair. Maybe this is not good?

[Psi]

I'm sure we have some CAN experts who can help.

[jahonen]

I'm no CAN expert but I think I can still provide some enlightenment. Maybe it makes more sense if you think how CAN driver works; it pushes CANL to ground and CANH to VCC whenever a bus transmitter transmits a dominant state (TXD = 0). For recessive state the CAN bus termination pulls bus lines together. No device will actively pull the bus lines to recessive state.

Regards,
Janne

[Rerouter]

i would say add some more lift up, those time constants look horrible, can high and can low are inverted from one another, so one should go high when the other goes low, and with such a slow rise time you are left with that mess,

[Spekkio]

The speed should be 125 000 kbit/s.
 
This is the transceiver that I use, VP231. http://pdf1.alldatasheet.com/datasheet-pdf/view/185386/TI/VP231.html

There is a "slope control" pin on the reciever. I have connected that to an I/O to the MCU, the voltage on the RS pin is ~0.2V
 
In the datasheet is specified, that  V(Rs) < 1V = High speed (no slope control)
 
Look at page 20 in VP231 datasheet. This is so that I can set the transceiver in standby when I don't use it.

[Spekkio]

i would say add some more lift up, those time constants look horrible, can high and can low are inverted from one another, so one should go high when the other goes low, and with such a slow rise time you are left with that mess,

Should I add a pull up on CANH, and pull-down on CANL ?

[jahonen]

i would say add some more lift up, those time constants look horrible, can high and can low are inverted from one another, so one should go high when the other goes low, and with such a slow rise time you are left with that mess,

Should I add a pull up on CANH, and pull-down on CANL ?

Put 120 ohm termination resistors to each end of your can bus, like shown in figure 33 of the datasheet.

Regards,
Janne

[Spekkio]

i would say add some more lift up, those time constants look horrible, can high and can low are inverted from one another, so one should go high when the other goes low, and with such a slow rise time you are left with that mess,

Should I add a pull up on CANH, and pull-down on CANL ?

Put 120 ohm termination resistors to each end of your can bus, like shown in figure 33 of the datasheet.

Regards,
Janne

I was told by a coworker to only have one 120 Ohm termination resistor on the CAN bus, because of the way it is designed. I only have one end of the CAN bus, not two.

I had 120 Ohm resistors in both ends to start with, then he told me to remove it.

Like this, Unit #1 only have one connector. The other ones, #2 and #3 have two connectors.

Unit #1 (also supplies +3.3V) -----> Unit #2 -----> Unit #3 ----> 120 Ohm.

But If it was like this I would have two.
In this setup, I would have two connectors on Unit #1

120 Ohm <----- Unit #3 <---- Unit #1 (also supplies +3.3V) -----> Unit #2 -----> 120 Ohm.

Is that correct?

[Spekkio]

I looked if +3.3V was dipping when sending a message, but it is stable.

Message looked a little bit better when I added a pull-up on CANH. Even CANL looked better.

I also looked whats happening on the  Rs pin, but it also looks stable at a very low voltage ~0.2V. I'm gonna keep looking 

[Spekkio]

I'm gonna try this and see if it works better, ofcourse I don't want it to consume alot of current when in sleep mode :/

I guess, since I'm using 3.3V, can I change the two 2k resistors, so that I get 2.5V in the middle? Would that work.. I'm gonna try anyway

[Rerouter]

if your using 3.3V, am i then right to assume the can bus devices are all 3.3V? if so just tie both channels with a 20K or less liftup to 3.3V, where is this 2.5V limitation from?

i apologize, I'm crossing my signals, CAN is differential so your buffered 2.5V method would be the way to do it correctly with less current draw.

[Spekkio]

if your using 3.3V, am i then right to assume the can bus devices are all 3.3V? if so just tie both channels with a 20K or less liftup to 3.3V, where is this 2.5V limitation from?

OK, I'm gonna take a better look. It looks like 2.3V when in recessive state. 3V CANH, 1V CANL.

[Spekkio]

The signals look a little bit better when I added the resistors, still they are a little bit slow in the rising edge but the sharp spikes atleast go all the way up.

Still got some software problems, MCU seems to lock with the FIFOEMPTY bit set, and it never wants to clear, even though there is no data on the can bus.
I'm trying to get some answers on the microchip forum on this problem :/ I thought maybe this had to do with the screwed signals so.

[PuterGeek]

Each end of CANbus needs a 120 ohm terminating resistor. A single resistor will work if the total length is short.

The only connections to the CANbus should be the transceivers. No other circuitry is needed and would degrade the bus.

The key is the bus is differential so probing the CAN High and CAN Low separately doesn't really work. A differential scope probe would be the 'correct' way to make the measurement. You could try separate probes on each line and use the scope's math function but it still won't 'look' right.

You can assume the transceivers are working unless they have been damaged. Compare the D pin of two transceivers on the bus and see if the signals are the same. If they are the bus is functional.

[Spekkio]

The key is the bus is differential so probing the CAN High and CAN Low separately doesn't really work.

Thanks, I did think about that, but wasn't entierly sure what could be wrong with measuring.

This is how it looks when I use two probes, one on CANH and the other on CANL. This isn't what I expect it to look like.
I thought 2.3V was in center, and then CANH to go up above 2.3V, and CANL to be inverted from that.



Maybe I'm not understanding how the can transceiver works correctly.
Maybe it is not possible to measure CANH/CANL with reference to ground? It is isolated somehow?
I was thinking about that before, but I couldn't really find any good answers.

It looks to me like you're measuring the signal without a ground path.

So you might actually be correct then?

[Spekkio]

Compare the D pin of two transceivers on the bus and see if the signals are the same. If they are the bus is functional.

Thanks! This worked, they are the same, so the CAN bus works.
I removed the pull-ups on CANH/L that I talked about befeo.
I measured the D pin in the transmitting side, and the R pin on the recieving side. They are identical.

I also noticed I probably need to add pull-up on the TX line between MCU and Transceiver. The built in pull-up on the MCU doesn't seem to be enough, or it is not activated correctly.

Then it is something in the software the makes it stuck in a  loop after 1 message. because I only get a response on the first transmitted message, directly after reset.
After that I, the other unit hangs in a loop inside Microchips AN930, J1939.C.

I set it up like this, one unit sends a message that the other unit will respond to.
Then I can press a button to send it again, that works, but I only get a response first time, then it's in a infinite loop trying to read the FIFO over and over.

But if I know there's nothing wrong with the signals on the bus I can keep working on the software...

Thanks! Now I learned something new about CAN

[Spekkio]

Found the error, there was a software error in Microchips AN930. The program only reads 1st receive buffer. But there are 8 buffers in PIC18F25K80, it seems that the PIC puts data in the next buffer next time I get a message. CANCON points to which buffer was used to receive the message, that pointer is increased by 1 every time I get a new message and then loops back to 0 again.

So I just needed to add some code in J1939.C from AN930, that checks which buffer to read from, then I can clear the FIFOEMPTY bit Actually it looks like it's clear automatically. AN930 probably haven't been updated in years...

Difficult to know whats wrong, when you don't know if the CAN bus messages are OK