[RESOLVED] Why IAR EWARM debugger resets STM32F7 in a weird way

[Pavel A.]

Apologize for IAR specific question, hope someone here can shed some light on my problem. I've tried to ask IAR support, but looks like they have a long weekend or whatever.

I have a bootloader at 0x08000000 and main app at 0x08008000.

The bootloader initializes something for the main app so it must execute every time before the app.

Pretty common thing, done many times with Atollic and CubeIDE.

But I cannot debug this with the EWARM debugger.

When I set the main app as active and start debugger, it enters the main app directly from its reset handler, without going thru the bootloader. No matter how I define the reset method - "system", "core" "connect under reset".

More to this - the reset button on the debugger toolbar has similar options - and none of these goes to the bootloader.

Unchecked run to main - does not help.

I tried to debug the bootloader instead, and load the main app as extra image.

This properly starts the bootloader, but after entering the main app source navigation ("find definition" or "find declaration") fails randomly. Both images share many common files, maybe this confuses the search. Thus I want to have the main app the active one.

Any advise how to force the IAR debugger to obey the "system" or "hardware" or "connect under reset" ?

The debugger probe is ST-LINK v3 mini with latest firmware, in SWD mode.

STM32F767.

EWARM version 8.40

[Mike_ST]

Hello,

I'm not sure this is related to a reset method.

If you uncheck the "Run To" "main" option in the debug options, maybe that can help you to see what is actually happening ?

[Pavel A.]

Thank you @Mike_ST​ . If "run to main" unchecked, the debugger stops in the assembly startup at reset handler of the main app. No way to reset to the boorloader, unless the bootloader itself is the active project.

[Mike_ST]

When debugging,

the Reset_Handler will call the __iar_program_start routine that will initialize

some stuff and then __iar_program_start will branch to the main() of the active project.

if you're confident enough, you can edit the startup_stm32f767.s Reset_Handler of your app to jump to the bootloader address:..

       LDR    R0, ="your bootloader address"

       BX     R0

but you have to configure the bootloader project to jump to the iar_program_start address of your app...

Please check the IAR technical note here:

https://www.iar.com/knowledge/support/technical-notes/general/creating-a-bootloader-for-cortex-m/

Maybe that can help you.

[Pavel A.]

Interesting idea, Mike. Thanks.

Then I'd rather use the IAR debugger script, a.k.a. "macro". Just had read on it.

The script can have several "hook" functions which the debugger calls on certain events.

Will update if this works.

P.S. Still haven't heard back from IAR support.

By contrast, Keil's support is very responsive and helpful. This alone is priceless.

OTOH, IAR better motivates the user to read the fine manuals...

[Pavel A.]

So, the suitable hook function in the debugger script is execUserExecutionStarted.

It is called when the debugger stops at main() (or reset handler) of the "active" image and is ready to continue.

In this function, I reset the MCU again, then it properly runs thru the bootloader, stops on main() and calls the execUserExecutionStarted hook again.

// main_app_debug.mac
execUserExecutionStarted()  {
  if (__messageBoxYesCancel("Reset to the bootloader?", "MAIN APP DEBUG"))
  {
   // NVIC_SystemReset:
   __var AIRCR;
   AIRCR = 0xE000E000 +  0x0D00 + 12;
   *((unsigned long*)AIRCR) = (0x5FA <<16) | (1<<2);
  } else {
   __message("Continuing main app...\n");
  }
}

So using a popup prompt to choose reset or continue. Later will figure out how to reset only once without a prompt.

Or instead of MCU reset just move the PC to the bootloader

execUserExecutionStarted()
{
  if (__messageBoxYesCancel("Reset to run the bootloader?", "MAIN APP DEBUG")) {
    __var BL_reset_PC, BL_SP;
    BL_SP       = *((unsigned long*)0x08000000);
    BL_reset_PC = *((unsigned long*)0x08000004);
    #PC = BL_reset_PC;
    #SP = BL_SP;
  } else {
   __message("Continuing main...\n");
  }
}

[Pavel A. · Accepted solution]

Final variant: removed user prompt, works silently.

Tested with EWARM 8.40

// This script ensures that bootloader always executes before the app
__var seenReset;
 
// This executes after the debugger resets the system
execUserReset()
{
   seenReset= 1;
}
execUserExecutionStarted()
{
   // This executes when the debugger stops at main() of the main app
   // We must execute the bootloader first, so move to the BL start addr and let the BL jump to the app.
  if (seenReset) {
    __var BL_reset_PC, BL_SP;
	seenReset = 0;
    BL_reset_PC = *((unsigned long*)0x08000004);
    BL_SP       = *((unsigned long*)0x08000000);
 
    __message  "BL_PC : 0x", BL_reset_PC:%X, "SP=", BL_SP:%X, "\n";
    #PC = BL_reset_PC;
    #SP = BL_SP;
    __message("execUserExecutionStarted -- after move");
  } else {
   __message("Continuing to main...\n");
  }
}

[Pavel A.]

I have to add that IAR support replied and pointed me to a helpful AN.

The IAR debugger can handle two images with duplicate symbols. Very nice. Though could be a bit faster.

[Piranha]

How about just forcing VTOR to 0x08000000?

https://renesasrulz.com/embedded-system-platform/synergy/f/forum/15746/iar-debug-commands

[Pavel A.]

yes, --drv_vector_table_base