• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 32 subscribers
  • Views 392 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

RM46L852: Bootloader initializes Can Bus, then Application attempts to but fails

RM46L852: Bootloader gets stuck in retransmit loop, even though hardware re-transmit is disabled.

Casey Gregoire
Intellectual 330 points

Part Number: RM46L852

We have any application that uses the TI CAN Bootloader sample as the basis of our CAN Bootloader. We are seeing an issue where when we send our first message to the device which expects a return acknowledgement message on the CAN Bus identifying the device, when this happens that device starts rapidly sending the same message repeatedly and never stops. We do observe 2 stuff errors then nothing but that same message over and over.

we tested with both the hardware re-transmit enabled and disabled:

canREG1->CTL = 0x00000000U | 0x00000020U | 0x00021443U;  /* both IE0, IE1 are 1*/

canREG1->CTL = 0x00000000U | 0x00000000U | 0x00021443U;  /* both IE0, IE1 are 1*/

but this did not change the behavior. we have checked the impedance on the bus and it is about 56-58 ohms.

What is odd, is this never happens when we run our application code on the same hercules based devices. All cards are using the same clock, CAN Bus Speed of 1Mhz, and the only setting i have found that is different is the interrupt setting, on the bootloader:

canREG1->INTMUXx[0U] = 0x00000011U

on the application:

canREG1->INTMUXx[0U] = 0x00000000U

Is there any software settings that might be causing this that i don't know about or might have missed?

  • 0 in reply to Casey Gregoire
    TI__Guru**** 201096 points

    Hello,

    The CAN node (lets define it as Node #1) with bootloader is waiting for the message from another node (lets define it as Node #0). CAN Node #1 is the data message receiver, and CAN Node #0 is the transmitter. The disabling the retransmission feature of CAN Node #1 (with bootloader) doesn't affect the retransmission from CAN Node #0.

    Does the Node #1 (with bootloader) send the ACK bit after receiving the correct data (the message frame 138.077398)? After CAN Node #0 receives the ACK bit from Node #1, it should transmit a new message. 

    If the ACK is correct, the issue may be caused by the code in your Node #0.

  • 0 in reply to QJ Wang
    Intellectual 330 points

    The Node that is repeatedly sending the message is node #1, and its the ack that its sending repeatedly, so i receives the packet that triggers an ACK, and returns ACK repeatedly non stop from that point on. Node #1 is the node I Disabled re-transmit on, which is why I ask this question.

  • 0 in reply to Casey Gregoire
    TI__Guru**** 201096 points

    It seems to me that the message with data "00 06 00 01 00 01" is transmitted by the Node #1 intentionally. The re-transmission is only triggered if an error occurs or it lost the arbitration. 

    Can you please share your bootloader code? The example bootloader doesn't transmit data data to other CAN Node.

  • 0 in reply to QJ Wang
    Intellectual 330 points

    I turns out we did something that I do not think follows the CAN protocol stand, and I apologize for not mentioning this in the original post. We have two devices on the bus that are getting update, and both boot loaders are replying with a message of the same ID. This causes issues with arbitration which leads to this result. we will fix it by change the id of the ACK for each device.