Trouble with CAN on LPC1788

[behnamshakibafa]

Hi everybody

I've got in trouble with CAN bus on LPC1788. I used the sample code of KEIL v5 (functions in attachment) to initialize CAN1 and sending data. now I have two problems:

1. After three times, the process goes inside the Error Handler and I don't know why?!

2. But the device continue sending data for a while since it is corrupted data between A and B outputs (see the picture below)!

 Does anybody know what's wrong?

Thank you

Behnam

Original Attachment has been moved to: LPC17xx-CAN.zip

[behnamshakibafa]

Ok, I found me second question answer. my Logoc Analyzer does not support differential signals, so i should use single ended method to monitor CAN.

But still, I don't know what happens in my code. The code stock in Error handler after three times I send data, but I can see data is on bus for ever!

This is my Send Data function

int32_t CAN_send(uint8_t *data, uint8_t size){
    int32_t                  status;

    status = ptrCAN->MessageSend(tx_obj_idx, &tx_msg_info, data, size);        // Send data message with 1 data byte
    if (status != 1U) { Error_Handler(); }

    return status;
}

[MartinHo]

A functioning CAN Bus needs at least 2 nodes (1 sending, and 1 answering with ACK) otherwise the sending Node will continuing sending his message until he reaches an internal error counter and goes in Bus-off state. I think that is was happening to You. Do You have a second node on Your CAN-Bus line? Please remember the termination on the bus has to be 2 x 120 Ohm.

Martin

[behnamshakibafa]

And just another point

When I use 120R on both two sides, the logic analyzer shows me corrupted packages, but with single ended 120R termination, one of signals is OK

[MartinHo]

OK, when I understand right, You are using two LPC1788 as nodes, both nodes are set to the same baud-rate, but on the CAN-Buy You see only a Can signal on one of the two CAN Lines (CAN_H or CAN_L?) and with the 2 x 120 Ohm termination, You see corrupted data (Attention CAN-Signals are not TTL, see the datasheet of Your CAN-Driver). This is not OK, so probably you have to solve first a HW problem.

What CAN-Driver do You use?

Do You have a common ground on both nodes? 

Have You tried to connect Your Logic-Analyzer to the CAN_TX and CAN_RX signals (CPU pin's) on both CPU?

Martin

[behnamshakibafa]

Dear Martin, Thank you for the help you are giving to me

You are right, this is what really happening

- I'm using TI sn65hvd233 3.3v CAN PHY.

- I can see CAN_H single ended using the logic analyzer (can see in picture) and they said it's OK to see only one side, because the analyzer does not support differential.

- I changed one side hardware and now its OK with 120R terminations. But still gives NAK at the end of packet.  

      Channel 0 -> CAN_TX , Channel 1 -> CAN_H

- Yes, I have common GND to both boards.

- Yes, the signal on CAN_TX is exactly same (but inverted) as what I see on CAN_H

It seems my receive side has a problem, but can't understand what is it?

May be in code? I can't find sample codes on new KEIL CMSIS API

[MartinHo · Accepted solution]

I don't think its normal to see the Data only on CAN_H, You should see the same signal as on CAN_TX on CAN_L (measured against GND, be award that the levels are about 2.3V (recessive) to 0.5V (dominant) only (or 2.3V to 3V on the CAN_H line)!

Do You have a Oscilloscope? As You use a fairly low bitrate (100 Kbit ?) even a 1 Mhz type will do the Job. To verify the effective waveform's?

An other test would be to connect Your Logic-Analyzer to the CAN_RX on the receiver side and see if You receive the Message You are sending.

If this is OK the next thing, is to check the CAN_TX on the receiver, You should see only the ACK bit.

If the ACK Bit is missing but the CAN_RX is OK then You have a SW problem on the Receiving node. Unfortunately I do n't use KEIL so I can't help You a lot with this, but there is a example in the LPCopen Library (LPCOpen Software for LPC17XX|NXP ).

Martin

[behnamshakibafa]

Nice, you said good way to debug finding ACK signal on receiver side, I found the problems in HW and SW and now it works. Thank you very much for your helps.

The last problem was in Rs pin of the CAN transceiver, it should be same on both sides.

Thank you so mcuh

Behanm

[behnamshakibafa]

Thank you Martin

Yes I have second node that listening, but always receiving 0x00 for all 8 bytes. Also I can see NAK at the end of frames. I think the problems should be on my receiver side as you mentioned, but just don't know what is it.

Here it is codes I added to sample code to receive packets on CAN bus

  memset(&rx_msg_info, 0U, sizeof(ARM_CAN_MSG_INFO));
  rx_msg_info.id = ARM_CAN_STANDARD_ID(0x12);
  rx_msg_info.dlc = 0x08;‍‍‍

int32_t CAN_read(uint8_t *data, uint8_t size){
     int32_t                  status;

     status = ptrCAN->MessageRead(rx_obj_idx, &rx_msg_info, data, size);        
     if (status != 8U) { Error_Handler(); }
     
     return status;
}‍‍‍‍‍‍‍‍