Skip to main content
Associate
July 14, 2026
Solved

STM32N6 diffrent behaviour Run and Debug config

  • July 14, 2026
  • 3 replies
  • 85 views

I'm facing a very strange issue on my custom hardware based on the STM32N6 when trying to run my application using the Run configuration in STM32CubeIDE.

 

My setup consists of a secure-only application with an FSBL and a separate application. The project is generated with STM32CubeMX, built in STM32CubeIDE, and uses TouchGFX. The build completes successfully.

 

Debugging the application works perfectly, and I don't encounter any issues. However, as soon as I try to launch the exact same application using the Run configuration, it stops working. Both the Run and Debug configurations use the same build and the same ".launch" settings.

 

The behavior is as follows:

 

1. I power-cycle the board while it is in development mode.

2. I start the application using the Run configuration.

3. The application does not produce any output on the display.

4. After a few seconds, the watchdog expires, the board resets, and it ends up in a boot failure state.

 

Interestingly, if I instead:

 

1. Power-cycle the board.

2. Launch the application in Debug mode.

3. Stop the debugger.

4. Program the application again using the Run configuration.

 

...the application runs correctly.

 

However, after the next power cycle, the problem returns: launching with Run again results in no display output, followed by a watchdog reset and boot failure.

 

I have also tried different compiler optimization levels, including -O0, but the behavior remains unchanged.

 

Has anyone experienced similar behavior or has any idea what could cause the Run configuration to behave differently from Debug, even though they use the same binary and launch settings?

Best answer by mz1

I found the issue.

 

It was caused by __WIF() call inside the DMA to FMC transfer-function. 

It was blocking in run mode so i replaced it with an HAL_Delay() now it works just perfekt.

Not sure why __WIF() was optiized out by the Debugger.

 

Many Thanks MGogr.1

3 replies

MGogr.1
Senior
July 14, 2026

You can try by commenting the watchdog code for time being and see if Run Configuration works properly.

If it works properly then their is some mistake in implementing watchdog.

mz1Author
Associate
July 14, 2026

I commented the watchdog. Now I don’t get an reset anymore.

The application still hangs.

 

Some more information:

  • The application uses FreeRTOS task to run my statemachine and also the TouchGFX Task.
  • I can observe that during debug the display is showing the correct ui.
  • When I run directly in Run mode the display is not showing anything.
  • As soon as i change something in the Task Prios I get the screen initialized but still no grafics on the screen.
  • And when i let it run the Watchdog hits somewhen.

It somehow seems that during debugging CubeIDE is placing some settings which aren’t placed during Run.

 

MGogr.1
Senior
July 15, 2026

The best to way to check for bug will be comment out all peripherals and uncomment one by one and find out which part of the code/peripheral works properly in RUN mode.

Then uncomment code part by part and check which peripheral/code starts to give problems.

Keep Watchdog commented out for whole session.

mz1AuthorBest answer
Associate
July 15, 2026

I found the issue.

 

It was caused by __WIF() call inside the DMA to FMC transfer-function. 

It was blocking in run mode so i replaced it with an HAL_Delay() now it works just perfekt.

Not sure why __WIF() was optiized out by the Debugger.

 

Many Thanks MGogr.1

Andrew Neil
Super User
July 15, 2026

It was caused by __WIF() call i

Did you mean __WFI() ?

 

Not sure why __WIF() was optiized out by the Debugger

__WFI()  puts the processor to sleep - the behaviour under the debugger can be different ...

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.