TMS320F28375S: CAN Data Not Updating After Jumping from Custom Bootloader to Application

Part Number: TMS320F28375S

Tool/software:

Hello team,

I am working with the TMS320F28375S microcontroller and have developed a custom CAN-based bootloader. Both the bootloader and the application are using FreeRTOS, and I am encountering an issue with the CAN communication after jumping from the bootloader to the application.

After flashing the application through the bootloader, when I jump to the application, the CAN messages are being received at the correct time, which means the messages are arriving as expected. However, the data within these messages appears stuck or is not updating. The CAN data in the messages does not change, even though the application is actively sending new data. This issue persists until I power cycle the microcontroller, after which the CAN data starts updating as expected, and everything works fine.

I suspect that the issue may be related to the proper re-initialization of the CAN peripheral when transitioning from the bootloader to the application. Specifically, I am concerned that there might be lingering old data in the CAN buffers or that the message object or interrupt configuration may not be properly reset when control is handed over to the application.

Here is the code I am using to jump from the bootloader to the application:

vTaskSuspendAll();

DEVICE_DELAY_US(100);

// 2. Reset timer and peripheral interrupts
SysCtl_disablePeripheral(SYSCTL_PERIPH_CLK_CANA);
CPUTimer_stopTimer(CPUTIMER2_BASE);
CPUTimer_reloadTimerCounter(CPUTIMER2_BASE);
CPUTimer_setEmulationMode(CPUTIMER2_BASE,
                          CPUTIMER_EMULATIONMODE_STOPAFTERNEXTDECREMENT);

// Disable global interrupts
DINT;
IER = 0x0000;
IFR = 0x0000;
asm("    NOP"); 
asm("    NOP");
asm("    NOP");
asm("    NOP");
DEVICE_DELAY_US(5000);

asm (" LB 0x088000");

Additionally, since I am using FreeRTOS in both the bootloader and the application, could the FreeRTOS task management or the way interrupts are handled be interfering with the CAN communication setup? I would appreciate any insights on how FreeRTOS might be affecting this behavior, and whether there are additional steps I need to take to ensure the proper initialization of the CAN peripheral after the jump.

Could you please confirm if the jump process I am using is correct or if I should make any modifications? Any suggestions or guidance to resolve this issue would be greatly appreciated.

Thank you!
Muzammil Qureshi

Hi Muzammil,

>The CAN data in the messages does not change, even though the application is actively sending new data.

Are you able to use to the MCAN_ReadMessage function or some variation of it? This function waits to receive a message from the host and upon successful receiving reads the message. It then proceeds to clear the message RAM. 

Further, once you jump to the application, is it doing anything to turn on the CAN peripheral again?

Thanks and regards,

Charles

Hi Charles,

Thank you for your suggestions. here i am talking about the data which the application sends.

Charles Roberson said:

Are you able to use to the MCAN_ReadMessage function or some variation of it? This function waits to receive a message from the host and upon successful receiving reads the message. It then proceeds to clear the message RAM. 

My application is using the CAN_sendMessage function to send data over CAN. When I observe the CAN messages on PCAN Explorer, the timing of the messages looks correct — the messages are arriving at the expected times. However, the content of the messages is not updating, even though the application is actively sending new data. It's almost as if the CAN message data is "stuck" or not being updated after the jump from the bootloader to the application.(for reading data, I use CAN_readMessage function. i use interrupt and every time i send or receive message, i clear interrupt status after that)

One interesting observation is that after powering off and then powering the microcontroller on again, the CAN data and messages are working perfectly, and the data content is updating as expected.

Charles Roberson said:

Further, once you jump to the application, is it doing anything to turn on the CAN peripheral again?

Regarding the initialization of the CAN peripheral after jumping from the bootloader, my application has a board_init function (defined in the SYS/CFG file), which is called every time the application starts. This function initializes all peripherals, including the CAN module, so I believe that the CAN peripheral should be properly re-initialized during the application startup. Despite this, the issue persists, which makes me think there might be some other configuration or state that needs to be addressed after the jump.

Thanks again for your support.

Best regards,
Muzammil Qureshi

Hi Muzammil,

Will discuss this with the CAN experts, look to get back to you in next few days.

Thanks and regards,

Charles

Hi Muzammil,

Can you try not re-initializing the CAN after boot run?

Thanks and regards,

Charles

Hello Charles,

Sorry, but I am not able to fully understand what you are exactly trying to convey. In my application, there are multiple CAN transmit messages, and I'm not sure how the CAN will run properly if I do not re-initialize it. Can you please clarify your suggestion?

On a related note, I have found a temporary solution. Since my problem is resolved by turning off the controller and then turning it back on, I added a device reset using the "SysCtl_resetDevice();" instruction before jumping to the application when the firmware is flashed. While this approach has worked, I still feel that it is not an ideal or proper solution. Do you think this solution is acceptable?

Looking forward to your guidance.

Thanks and regards,
Muzammil

Hello Charles,

I don't know if there is a glitch or something else but I haven't received a response yet and wanted to kindly inquire if there have been any updates or if additional information is needed from my side to help resolve the matter. Your assistance would be greatly appreciated, and I would be grateful for any guidance or feedback.

Thank you in advance for your time and support!

Best regards

Muzammil Qureshi

Hello,

I don't know if there is a glitch or something else but I haven't received a response yet and wanted to kindly inquire if there have been any updates or if additional information is needed from my side to help resolve the matter. Your assistance would be greatly appreciated, and I would be grateful for any guidance or feedback.

Thank you in advance for your time and support!

Best regards

Muzammil Qureshi

Hello, 

The thread was wrongly auto assigned, I have assigned it to appropriate Subject Matter Expert.

Apologies for the inconvenience and delay

Regards, 

Subham M

Hello,

Muzammil Qureshi said:

On a related note, I have found a temporary solution. Since my problem is resolved by turning off the controller and then turning it back on, I added a device reset using the "SysCtl_resetDevice();" instruction before jumping to the application when the firmware is flashed. While this approach has worked, I still feel that it is not an ideal or proper solution. Do you think this solution is acceptable?

This may be exposing the underlying issue. Are you clearing the Rx message buffer between the jump from the bootloader to the application?

Best,

Matt

Hello Matt,

Thank you for reply. I appreciate the response, even though it took quite some time to hear back.

Regarding your suggestion, I believe the issue might indeed lie in the Rx message buffer not being cleared when jumping from the bootloader to the application. Could you please guide me on the best way to clear the buffer? Should I use a specific driverlib api function or approach to ensure that the Rx message buffer is properly cleared before the transition?

I clear the CAN interrupt and global interrupt every time i receive message.

here is how i jump from bootloader to app.

static void JumpToApplication(void)
{
    // 1. Stop the RTOS tick timer
    vTaskSuspendAll();

    DEVICE_DELAY_US(100);

    // 2. Reset timer and peripheral interrupts
    SysCtl_disablePeripheral(SYSCTL_PERIPH_CLK_CANA);
    CPUTimer_stopTimer(CPUTIMER2_BASE);
    CPUTimer_reloadTimerCounter(CPUTIMER2_BASE);
    CPUTimer_setEmulationMode(CPUTIMER2_BASE,
                              CPUTIMER_EMULATIONMODE_STOPAFTERNEXTDECREMENT);

    // 1. Disable global interrupts
    DINT;
    IER = 0x0000;
    IFR = 0x0000;

    asm("    NOP");
    asm("    NOP");
    asm("    NOP");
    asm("    NOP");
    DEVICE_DELAY_US(5000);

    asm (" LB 0x088000");
}

Is this correct or should i do changes to it?

thanks for support

Muzammil Qureshi

Hi Muzammil,

Given this a more niche issue, I had to take the time to discuss with multiple experts:

Initializing the CAN module would trigger the initialization of the message RAMs, effectively clearing the CAN buffers. In fact, the message RAM initialization bit flag is polled during CAN init routine to ensure that message RAMs have completed the initialization sequence within CAN init routine.

Given that a reset is the only thing that makes the device behave correctly, there must be a setting configured in the bootloader that needs to be reset/reconfigured after branching. Without taking a comprehensive dive into the code, the best I can recommend is compare the contents of the CAN config registers (In CCS, View > Registers) before and after a reset. You can also look at the CAN registers while the device is receiving frames to see what's going on.

Best,

Matt