Chris Keydel

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

10 years, 1 month ago.

CAN bus not working

I just got my first mbed LPC1768 and within a few minutes, created this very simple program to test CAN transmission:

#include "mbed.h"
CAN can1(p9, p10);
//CAN can2(p30, p29);

int main() {
    int  result;
    char data = 0xAA;
    
    result = can1.frequency(125000);
    while(1) {
        wait(1.0);
        result = can1.write(CANMessage(1337, &data, 1));
    }
}

Alas, it doesn't work at all. When I connected it to my CAN transceiver I couldn't pick up the sent messages. Then I disconnected the mbed and measured the bare CAN_TX pin (DIP10) and the signal looks like this:

/media/uploads/hello_world_dot_c/capture.png

The first long low pulse could be an error frame. The many following low pulses have the right length for 125 kbps but of course this is not a proper CAN frame but something horrible.

There is nothing connected to the receive pin (DIP9) and it stays high the whole time.

Also tried CAN2 at DIP29/DIP30 with the same result.

Do I have a faulty chip/board?

Chris

1 Answer

Andy A
10 years, 1 month ago.

If you have nothing connected to the can pins when you measured that could you be falling foul of the CAN bus arbitration protocol? I'm not a CAN expert but I believe that if the receive data doesn't match the transmit data the CAN controller will think it has lost the bus arbitration and back off the transmission.

The CAN bus expects to be connected to a CAN transceiver chip with a bus termination resistor. Without those parts on there it's probably not going work right.

Accepted Answer

Duh! Don't know how I could have missed that.

Indeed - the RX pin has to reflect what's transmitted on TX outside of the acknowledge bit. It can also happen during the arbitration phase (identifier and IDE/RTR bits) which causes the CAN controller to stop transmitting.

If it happens anywhere else, this is a protocol error which causes the CAN controller to see an error right away. Several of those in a row lead to the controller going bus off. This is what happens with no transceiver connected - the RX line stays high.

Case closed. Thanks!

posted by Chris Keydel 07 Oct 2014