• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 286 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:

TM4C129ENCPDT: Free RTOS configuration

TM4C1294NCPDT: FreeRTOS App Linked to Run at non-zero address

John Gerthoffer
Prodigy 40 points
Part Number: TM4C1294NCPDT

I am having trouble debugging my already working FreeRTOS application after changing the APP_BASE location.  The debugger does not Run to symbol "main", it just hangs.  However, after deselecting the Run to symbol option, is lands at PC = 0x0100xxxx, the ROM bootloader.

I have read through various Bootloader examples.  I can debug the TI example boot_demo1 and have verified PC = 0x00004xxx.  Run to symbol "main" and stepping through app works.  For comparison, if the boot_demo1 Run to symbol option is disabled, PC=_c_int00_noargs().

Any ideas or tips appreciated.

  • 0
    TI__Guru**** 190806 points
    John Gerthoffer said:
    I am having trouble debugging my already working FreeRTOS application after changing the APP_BASE location

    Hi,

     If you change APP_BASE from 0x0 to a non zero address then what is at 0x0? Normally, you would have some type of bootloader at 0x0 so that it can jump to your application at the new APP_BASE. If you don't have anything at 0x0 then it will not work. After reset, the processor starts at 0x0 expecting a valid stack pointer at 0x0 and a valid reset vector at 0x04. 

  • 0 in reply to Charles Tsai
    Prodigy 40 points

    Thank you for your reply.

    Charles Tsai said:
    then what is at 0x0?

    A flash bootloader will be located at 0x00000000 similar to the Bootloader examples I have experimented with.

    Charles Tsai said:
    After reset, the processor starts at 0x0 expecting a valid stack pointer at 0x0 and a valid reset vector at 0x04.

    Understood.  Can you explain why I am able to load the TI example boot_demo1 with the debugger?  (with noting programmed at 0x00000000)

  • 0 in reply to John Gerthoffer
    TI__Guru**** 190806 points
    John Gerthoffer said:
    Can you explain why I am able to load the TI example boot_demo1 with the debugger?  (with noting programmed at 0x00000000)

    That is more a debugger (e.g. CCS) thing that forces the PC (program counter) to the main() after you first load the boot_demo1. For detailed explanation, the CCS team can answer better than me as I might be incorrect on how CCS manipulates the PC. I know for sure, without anything at 0x0, it will not work once you do a reset whether inside CCS or using the external reset pin. As mentioned, if there is nothing at 0x0 and 0x4, the processor does not know how to procced the code execution. Please make sure you have a bootloader at 0x0. I will suggest you run the stock examples: boot_serial (the bootloader) and boot_demo1 (the example application) to get a feel of how TivaWare bootloader works despite this is a bare-metal implementation without RTOS. The boot_serial will reside at 0x0 and boot_demo1 will reside at 0x4000 if you look at the APP_BASE in boot_demo1.cmd file. 

  • 0 in reply to Charles Tsai
    Prodigy 40 points
    Charles Tsai said:
    I will suggest you run the stock examples: boot_serial (the bootloader) and boot_demo1 (the example application) to get a feel of how TivaWare bootloader works

    OK, I have worked through a couple boot loader examples.  The TI boot_xxxxx and a great example from Chester Gillon <https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1024278/tm4c1294ncpdt-rtos-bios-not-working/3787593#3787593>  Chester's example is very close to what I had in mind.

    I am able to debug both Application examples from TI and Chester Gillon.  The TI tools load the application at the given address defined in the linker blah_blah.cmd file.  e.g. FLASH (RX) : origin = 0xXXXXXXXX, where 0xXXXXXXXX != 0x00000000.

    I can begin to debug one of the TI FreeRTOS examples (ssi_simple_xfer), but it crashes in portasm.asm function vPortStartFirstTask when it tries to load the vector table and stack pointer addresses from NVIC_NVIC_VTABLE.  This is because NVIC_NVIC_VTABLE register is 0x00000000.  

    And just as

    Charles Tsai said:
    if there is nothing at 0x0 and 0x4, the processor does not know how to procced the code execution.

    Temporary Workaround: For testing, I manually set NVIC_NVIC_VTABLE = app location in linker .cmd file and it goes! 

    FreeRTOS' vPortStartFirstTask loads the stack pointer from the vector table. 

    For reference, It appears that neither boot_demo1 nor TI RTOS boot.asm reference NVIC_VTABLE on startup.
    TI RTOS boot.asm loads the stack pointer from symbol c_stack.  It also references the reset vector via symbol c_reset.