• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 605 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:

TM4C1290NCPDT: Branch or Jump to particular address

TM4C1290NCPDT: TM4C address jump

Yasar Arafath
Intellectual 500 points
Part Number: TM4C1290NCPDT
Other Parts Discussed in Thread: UNIFLASH, EK-TM4C1294XL

Hi All,

I have implemented an logic which writes successfully to the TM4C ROM at 0x80000 with length ~69632 bytes, which I verified by reading the TM4C ROM with Uniflash tool.

But when I do jump with below statements the control is not transferring to the particular address.

// Set the vector table to the beginning of the app in flash.
 HWREG(NVIC_VTABLE) = 0x80000;

// Load the stack pointer from the application's vector table.

 __asm(" ldr r1, [r0]\n"
 " mov sp, r1");

 // Load the initial PC from the application's vector table and branch to
 // the application's entry point.
 
 __asm(" ldr r0, [r0, #4]\n"
 " bx r0\n");

Kindly suggest that I am missing out anything.

Thanks & Regards,

Yasar Arafath

  • 0
    TI__Guru**** 191826 points

    Hi Yasar,

      At first glance I do not see a problem with the code you wrote to jump to the application start address. After you execute the bx instruction where does the PC (program counter) go?

  • 0 in reply to Charles Tsai
    Intellectual 500 points

    Hi Charles,

    After executing the bx instruction the PC is showing the value 0x8FB3C.

    Thanks & Regards,

    Yasar Arafath

  • 0 in reply to Yasar Arafath
    TI__Guru**** 191826 points

    Hi Yasar,

      Do you have correct SP and reset vectors at 0x80000 and 0x80004? What value is the r0 loaded with? Even though it shouldn't have a different behavior, I'm wondering what you will get if you change to a small address (i.e. 0x4000) instead of 0x80000. Can you try?

  • 0 in reply to Charles Tsai
    Intellectual 500 points

    Hi Charles,

    In the meanwhile I tried the same which you have suggested above. I tried to boot from 0x50000, then also same issue.

    After writing into TM4C ROM we are forcefully RESTARTING the devcie. And additionally we implemented the bootloader code which will look for the data in particular address and it will boot the binary.

    This approach is working fine rather than direct branching.

    Thanks & Regards,

    Yasar Arafath

  • 0 in reply to Yasar Arafath
    TI__Guru**** 191826 points

    Hi Yasar,

      Glad your problem is resolved. I didn't realize that you were trying to implement a bootloader. We have a few bootloader examples which does exactly the same. You can take a look at the pair of examples such as boot_serial (this is the UART bootloader residing at 0x0) and boot_demo1 (this is an application residing at 0x4000 which will jump to the bootloader). You can find them in <TivaWare_Installation>/examples/boards/ek-tm4c1294xl

      After you program your application to address (i.e. 0x80000) you need to reset the device. After the reset your bootloader will check if an application is present at 0x80000 with the correct stack pointer and the reset vector. If there is nothing at 0x80000 then the bootloader will start the bootloading process. If there is already an application at 0x80000 then the bootloader will just jump to the application to start execution. Your application can add code to jump back to the bootloader if there is a command received to update a new FW image. I think this is what you are currently doing to make it work and this is also how the TivaWare bootloader example is handling a new application update.