TMS320F28069: Jump to Application from bootloader when running from flash

Robert Fleury said:

What I observe is that the bootloader lights will blink as expected, but then it just seems to hang, the times I have been able to see what instruction was executing, it looked like it was stuck in boot rom somewhere.  

Robert,

A couple of thoughts come to mind:

• Watchdog fired and reset the device.  If this occurs the device should have gone through the same boot sequence and the LED would flash again so this may not be it.  You can monitor the reset pin with a scope to see if the device does reset. 
• The flash kernel, constants used by the flash kernel, or the flash API call-back function, were not copied and available from RAM.  If the API tried to modify the flash then anything in flash will no longer be available to the CPU for running the API.  This would probably cause an ITRAP.   If you can determine where in the boot ROM it gets stuck and if that corresponds to an ITRAP.  You can also try initializing the PIE vector table with your own ITRAP handler - maybe toggle a different IO there or toggle at a different rate. 
• Make sure all initialized sections start in flash (then run from RAM). Examine the .map file for initialized sections loading directly to RAM. Try running your kernel with the debugger attached to debug where things go wrong.  The key is to make sure CCS doesn't load anything into RAM that would not be present after a power-cycle.  This can be done by power-cycling the device and loading only the project symbols after reconnecting. 

Regards

Lori

Here is my latest update:

I have pretty much the same setup: (flashing (with jtag) the blinky light flash app on sector C Flash and loading it properly, then flashing (with jtag) the bootloader app to sector A, and not erasing other flash sections).

Everything works when debugging, but when I switch the boot mode switches on my launchpad and reconnect power, the bootloader lights blink, but then it hangs..

Here's my observation I need help with.

  If I put the line"

             ((void (*)(void))0x3ec6c0)();

  At the end of my main function in the bootloader, everything works after reset!  

The original code for the flash app returns the same address to the rest of the ExitBoot routine..


I then modified the exit boot routine to just cut out everything to try to make it as similar as possible to the direct function call above like so:

_ExitBoot:
PUSH ACC

POP RPC

LRETR



And it still doesn't work after reset, but does work in jtag debug mode.

I suspect that the ExitBoot routine isn't being called on reset, but I can't find a good reason why.  The address of all the functions are in flash.  I stepped through the assembly code and made sure all instruction addresses were in flash.

As further evidence of the InitBoot/ExitBoot not being called is that I put multiple calls to main in the asm functions, and I don't see them execute on reset, only in debug.

Is there some key piece of info I am missing here to get those asm functions to run on boot?

I read somewhere on the forums that the -entry_point linker option is only for debug purposes.  Is that true?  

If I remove the -entry_point linker option. I see that the program never runs the exitboot/initboot functions.

I guess that kinda leads to my next question of...

What is the purpose of the InitBoot and Exitboot functions?

Just to serve as a stripped down _c_init00?

Is the cleanup of ExitBoot necessary before starting a new application?  I would think garbage in those locations would be ok in general?

Robert Fleury said:

I read somewhere on the forums that the -entry_point linker option is only for debug purposes.  Is that true?  

Yes this is true.  The debugger will use this to force the C28x's program counter to that location when a "restart" is performed.   Typically we point the -entry_point in our examples to the codestart symbol of the application.  

A "reset" will instead reset the device and from there go through the boot process. 

There are some Code Composer options  under tools -> debugger options -> auto Run and Launch Options that can change the behavior. Uncheck the Auto Run Options if you want to step through the boot ROM for any reason.  

Robert Fleury said:

What is the purpose of the InitBoot and Exitboot functions?

There are comments in the source file that describe the functions.  For InitBoot it sets up the minimum CPU operating mode flags required to run C-code after a reset.  Once these are set once, you shouldn't have to re-set them.  As you say it is a stripped down _c_init00

For ExitBoot - The idea was to put registers back in their default setting (except a few operating mode flags for C28x).  It shouldn't really be required before jumping to _c_init00.  Even deallocation of the stack since  _c_init00 will re-initialize the stack pointer. 

Robert Fleury said:

Everything works when debugging, but when I switch the boot mode switches on my launchpad and reconnect power, the bootloader lights blink, but then it hangs..

You mention changing the boot mode from your debugging session to your stand-alone session.  You should be able to use the same mode during debug.  For example,

• set a breakpoint where the boot ROM exits
• Reset the device and run
• This will load your kernel through SCI and then halt before the ROM jumps to the kernel.  

You can then step into your kernel and see what is missing. 

-Lori