• AVR Freaks

Hot!Bootloader only executes loaded app when debugging

Author
PfunnyGuy
New Member
  • Total Posts : 10
  • Reward points : 0
  • Joined: 2012/07/25 21:15:03
  • Location: 0
  • Status: offline
2021/02/26 19:27:59 (permalink)
0

Bootloader only executes loaded app when debugging

Dev Kit: SAM-E70 Xplained, using a modified version of the Atmel bootloader to download new apps over I2C.
1) It will download over I2C.
2) It will download into the correct memory region
3) It will not reboot. 
 
I decided to just program the two applications into FLASH from MPLAB X.  When debugging (and this is for both methods of debugging: "Debug Main Project" and "Launch Debugger Main Project", where the main project is the bootloader (because that loads into the executable address of FLASH), it consistently experiences a HW fault with the same conditions (even when I make small code changes and recompile).  If I pause and look at the Call Stack: Hard Fault @PC Address 0x40a1aa.  This address is in the valid address range of executable memory.  If I look at the disassembly, it says "Debug information is not available @ PC 0x4B59615A".  If I look at the PC in the Variables tab the value of PC is 0x4B59615A.  Every single time. 
 
Next, (again, regardless of debug method) if I restart and hit Play, my application (a simple blinky-LED "Hello World" thing) always runs.

Here's the mind-bender: If, when I Launch Debugger Main Project, I don't press F5 (execute) but instead use F8 to step through the Reset_Handler(), as long as I step 2 or 3 high-level (i.e. C) instructions into the function, and then hit F5, my blinky-LED does run.  Which makes no sense - it will run the first time only if I step into the code?
 
There is a statement if(_on_reset) _on_reset();  to run a user-defined on-reset function, so I put a little loop in there that nops thinking that the stepping through added just enough time for some part of the HW to stabilize, but that doesn't do anything.  I have also used that function to disable the WD timer, but that did nothing. 
 
I'm at a loss, because I cannot use a debugger to make a deployed application run.  And I'm at a point where I feel like it has to be something either in the tool, compiler, or HW, not my code.  (NOTE: Every time I've made this claim in my life, it turns out to not be those things, so hopefully by making the claim I'll get another slap in the face from the universe.... Here's hoping!)
 
Also, I've pinpointed how far I need to step into the code in order to have my branched-to application run (This is not my code, but Microchip code):
void __attribute__((optimize("-O1"), section(".text.Reset_Handler"), long_call)) Reset_Handler(void)
{
    uint32_t *pSrc; 
    if (_on_reset)         _on_reset();       /* Call the optional application-provided _on_reset() function. */
    if (__xc32_on_reset)   __xc32_on_reset(); /* Reserved for use by MPLAB XC32. */

#if (__ARM_FP==14) || (__ARM_FP==4)
    /* Enable the FPU if the application is built with -mfloat-abi=softfp or -mfloat-abi=hard */
    FPU_Enable(); // If I press F5 here - it never works
#endif

    TCM_Configure(0); // If I press F5 here, it always works.

 
BUT BUT BUT
 
If I define 
void _on_reset( void ) {
    asm( "nop" );
}

Then: If I use F8 to single step to the second if-statement and press F5, it all works as expected.  The only common denominator here is the return from a function (though FPU_Enable() is an inline function).
post edited by PfunnyGuy - 2021/02/26 20:02:50
#1

0 Replies Related Threads

    Jump to:
    © 2021 APG vNext Commercial Version 4.5