• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 324 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.

A "third class" bootloader jump to 0x00 does not work, why?

stephen zhou
Prodigy 40 points

Hi:

I use C6713 with a UART(16L784). I didn't use DSP/BIOS.
I make a application with a secondary bootloader, just call it MYAPP, it work well.But the system can not update dynamically.
So, I make another application, just call it MYLOADER. MYLOADER also has a secondary bootloader.
I burn MYLOADER to 0x90000000(sections 0~3 of flash), it can boot up successful.
In MYLOADER, I burn MYAPP to 0x90040000(sections 4~7 of flash).
So I hope MYLOADER could load MYAPP's secondary bootloader to RAM addr 0x00, which means copy (0x90040000 ~ 0x90040400) to (0x00 ~ 0x400).
Then branch to 0x00, and run the MYAPP's secondary bootloader.
MYAPP's secondary bootloader then copy the rest code to IRAM, and branch to _c_int00.

The problem is that: MYAPP could not boot up successful. It seems that CPU run fly-away.
                     When I delete some code of function main, make a simple loop, just light a led and send some infomation to UART, It can work Well.
                    
                    
My stack size is 0xa000, heep size is 0x1000, I think it's not small.
So, I'm not sure maybe some registers was be modified by MYLOADER, and not set to it's default value when PC jumps to 0.
It affects MYAPP runing.
I wonder if there is some way to set the register to is default value, whitout a hardware reset.
can anybody help me?

  • 0
    TI__Mastermind 41665 points

    Are the code sections for either of your boot loaders overlapping, i.e. do they use the same physical address space? The one thought that comes to mind would be some form of program cache coherency problem, as L1D is not automatically coherent with L1P, L1P has minimal coherency built in, it essentially does not take into account self modifying code, which could include CPU loaded code in a boot loader like this. Details on these operations can be found within SPRU656.