STM32F091 crashes during debug but runs normal without debugging

[Curtis B.]

Hi everyone,

I observed a strange behaviour while creating software for a STM32F091. I am using CubeIDE and HAL. FreeRTOS is used as well. The application is running as expected so far, but when I try to run it in debug mode it does not work. It crashes at different locations within the HAL_Init() function. Did someone experienced a similar behavior and probably has a solution?

Best regards

[Tesla DeLorean]

Need bigger stacks or has asserts()? Instrument and check.

[Curtis B.]

I have not enabled full assert in the Prohejt Manager for Code generation. Should I? Stacks are as high as in other projects for the same tasks. Should it not crash as well when I run it without debugger if stack size is too small?

BR

[Issamos]

Hello @Curtis B. 

I suggest you to use this post to verify your debug configurations. Else maybe you have to take a look on this article and the AN4989 that could help.

Best regards.

II

[TDK]

What does crash mean here? What locations within HAL_Init does it happen at?

 

[Curtis B.]

Crash means that it says: "Break at address "0x1fffdabe" with no debug information available, or outside of program code." It happens either when I step over the line "HAL_NVIC_EnableIRQ(TIM6_DAC_IRQn);" in the Tick Init or when I step into this line I can go as far as "HAL_MspInit();" where I can not step into any more.

[Curtis B.]

I set up a new test project without RTOS an so on just with a blinking LED. Same behavior...

[Tesla DeLorean]

Unoptimized code may use more stack for local/auto variables. Optimized code can use registers more or fold stack contexts.

Measure actual maximal stack depth.

[Tesla DeLorean]

Check BOOT0 is pulled low. Check Vector Table mapping / memory mapped at zero.

[waclawek.jan]

One of those infamous "system memory mapped" cases, in this case probably due to PEMPTY. Debugger (I mean particular steps the debugging software takes) may or may not be involved; but maybe it's just the particular method how you approach debugging.

Try first just program the chip and power-cycle, and then proceed with debugging (i.e. the last power cycle before debugging must be with nonempty FLASH).

If this won't help, it's the debugger. As it might be tricky to fight, as the first step in your program, before enabling any interrupts, explicitly map user FLASH at 0.

JW

[Curtis B.]

@jan and @Clive: That are good hints. I suspect a slack joint at the BOOT0 pin. I have to check this when I am done with the grind today...

Best regards