• State Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 5 replies
  • Subscribers 30 subscribers
  • Views 713 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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:

Issue with bootloading and RTOS

TMS570LC4357: Issue with Bootloader and FreeRTOS application

tanmoy deb
Prodigy 20 points
Part Number: TMS570LC4357

Dear Team, 

I am facing a issue while running the Bootloader over CAN (as referred in spna241.pdf) and running an demo application with FreeRTOS kernel.

I have created an application with couple of tasks, Message Queue and Timer etc. The application can run successfully while the Base VECTOR address has kept at 0x00000000. While I am trying to run it with new Address as mentioned in document, 0x0010020, it fails to create the Tasks, Queue etc. While analyzing the problem I found that it fails to execute BaseType_t xRunningPrivileged = prvRaisePrivilege() API. 

I tried some solutions provided in the different TI forum discussions. 

Using the intvecs.asm, like this : 

b _c_int00

b #0x0007fff8

b #0x0007fff8

b #0x0007fff8

b #0x0007fff8

b phantomInterrupt

application can now do the SWI and init the tasks, queue etc successfully. But Bootloader now restarts while try to start the Application. It is stuck in : 

g_ulTransferAddress = (uint32_t)APP_START_ADDRESS;
((void (*)(void))g_ulTransferAddress)();

Please provide your input to solve this issue. 

  • 0
    TI__Guru**** 186196 points

    What is APP_START_ADDRESS defined in your code?

    It should be 0x10020 rather than 0x10000. BTW, the 0x0007fff8 should be 0x10020-0x8=0x10018.

  • +1 in reply to QJ Wang
    Prodigy 20 points

    Thank you for your input. 

    The APP_START_ADDRESS is 0x10020. 

    The bootloader intvecs.asm is like as below  now:

    b _c_int00
    b #0x10018 ;0x0007fff8
    b #0x10018 ;0x0007fff8
    b #0x10018 ;0x0007fff8
    b #0x10018 ;0x0007fff8
    b phantomInterrupt
    ldr pc,[pc,#-0x1b0]
    ldr pc,[pc,#-0x1b0]

    This still hangs in the bootloader while jumping to the APP_START_ADDRESS 

    Current observation is the Applications starts OK, while started from the debugger. The application booting is not working while from bootloader. 

    Please provide your feedback. 

  • 0 in reply to tanmoy deb
    Prodigy 20 points

    Some new observations : 

    resetEntry
          b #0x0010018 ;good hack :))

          b _c_int00

    undefEntry
         b #0x0010018
    svcEntry
         b #0x0010018

    prefetchEntry
         b #0x0010018
    dataEntry
         b #0x0010018
         b phantomInterrupt
         ldr pc,[pc,#-0x1b0]
         ldr pc,[pc,#-0x1b0]

    With this the Bootloader can jump now at Application after the POR(Power on Reset). But i don't understand the logic. Please explain and guide the right instruction for this.

  • 0
    Prodigy 20 points

    Dear QJ Wang, 

    I need some help, currently with the changes in the bootloader intvecs.asm, the bootloader can jump to RTOS app successfully in EVK and our custom board. 

    1. In evk, the code executes successfully with POR also, but in custom board this stucks in bootloader and never jumps into the APplication. I can see the Error LED is ON on our custom board. 

    2. I have tried with unchecked the Auto ECC generation option in the bootloader application, but could not get any success in compilation. (I found this suggestion in some of your other replies). 

    3. While the debugger connected, the bootloader and application loads successfully in DEBUG mode and LOAD application mode. 

    4. The part no# of the MCU we are using is TMS5704357BZWTQQ1. 

    Do you suggest anything to solve this issue. 

  • +1 in reply to tanmoy deb
    TI__Guru**** 186196 points

    Why do have two instructions for reset entry? The b _c_int00 is not called forever. After reset, the code jumps to 0x0010020 (application) directly.

    resetEntry
          b #0x0010018 ;good hack :))

          b _c_int00

    Please change back to:

    resetEntry
          b _c_int00

    After reset, the code jumps to _c_int00 in your bootloader, then your bootloader main() file< Your main() checks if the application needs to be updated or not. If not, the code jumps to your application using:

    ((void (*)(void))g_ulTransferAddress)();

    The linker cmd file of your application should be changed:

    VECTORS (X) : origin=0x00010020 length=0x00000020