The TI E2E™ design support forums will undergo maintenance from Sept. 28 to Oct. 2. If you need design support during this time, contact your TI representative or open a new support request with our customer support center.

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.

CC2642R-Q1: NoRTOS_start not working in RAM

Part Number: CC2642R-Q1

Hi,

I'm working on CC2642 Chipset, and wrote a bootloader to jump into application and update application image, it's working fine. Recently I want to update Bootloader itself, so I tried to build a Ram loader which is sharing the same code as bootloader with different link file, and the difference is all flash addresses used in BL are replaced with RAM addresses, but it failed at bootup. After some investigation, it looks like the scheduler started with "NoRTOS_start" is not working in this situation. Here are some debugging information I did locally:

1) After jump to ram loader, there is no response in the system, and I found that it stops in function "HwiP_dispatch" every time I attach JTAG with it. But it still allows me to step into the source code, and jump to main function from "HwiP_dispatch". But it will be stuck again if I try to continue the process or even try to "Step over" a function.

2) To confirm if this is related to the NoRTOS scheduler, I did two tests:

a) Add the dead loop before "NoRTOS_start" call with a counter, like:

volatile int i = 1, counter = 0;

while (i) {
    counter++;
}

Every time I pause the JTAG, I can see the counter is changing. This means the system is still running after jump.

b) Add above code block after "NoRTOS_start", same thing happens like step 1): unless I manually step into the dead loop, the counter won't increase.

I checked the code of "NoRTOS_start", it just calls the function "HwiP_enable", no other special called.

Could you help check this issue and give me some solution?

Thanks,

Xiaofeng

  • Hello Xiaofeng,

    I don't fully understand your application.  Since there is a JTAG connection available, it makes more sense to directly update the Bootloader flash directly than going through a RAM loader.  SRAM is needed for heap/stack/variable storage and it is extremely uncommon to use it for application code, especially since this memory is not retained after a device reset.  Depending on your command linker file changes it may be possible that the RAM application code conflicts with the other SRAM usage mentioned.  Another option is to use a secondary Bootloader flash space to update the primary area, however I cannot recommend using RAM for this purpose.

    Regards,
    Ryan

  • Hi Ryan,

    We're trying to update Bootloader over OTA once our ECU is delivered, and there is no enough flash space for the 2nd bootloader, so Ram loader is the best option for now. To resolve the conflict, I specially reserve the RAM space for RAM loader, so the conflict should be evitable. 

    Thanks,

    Xiaofeng

  • After some rework, I removed the call "NoRTOS_start" from my bootloader, and scheduled all works with timer and interrupts, now it's working fine. I didn't look into the code of the scheduler, anyway, it's working fine now. Thanks Ryan!