Skip to main content
Curtis B.
Curtis B.
Associate III
September 3, 2023
Solved

STM32F091 crashes during debug but runs normal without debugging

  • September 3, 2023
  • 13 replies
  • 4898 views

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

This topic has been closed for replies.
Best answer by 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

13 replies

Tesla DeLorean
Tesla DeLorean
Guru
September 3, 2023

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

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
Curtis B.
Curtis B.Author
Associate III
September 3, 2023

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
Issamos
Super User
September 3, 2023

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
TDK
September 3, 2023

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

 

"If you feel a post has answered your question, please click ""Accept as Solution""."
Curtis B.
Curtis B.Author
Associate III
September 3, 2023

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.
Curtis B.Author
Associate III
September 3, 2023

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

Tesla DeLorean
Tesla DeLorean
Guru
September 3, 2023

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.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
Tesla DeLorean
Tesla DeLorean
Guru
September 3, 2023

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

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    waclawek.jan
    waclawek.janBest answer
    Super User
    September 4, 2023

    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.
      Curtis B.Author
      Associate III
      September 4, 2023

      @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

      Terms & ConditionsAccessibility statement