cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H7 corrupt program counter already in Reset_Handler

Ekowa.2
Associate II

Hello All,

I use the STM32H743ZI MCUs on self designed boards. Most boards run without problems with the developed firmware. But some boards ( -were ok before- ) suddenly show a strange behavior. The STM32H7 seems to reset continuously at first sight. 

For test purposes I wrote a simple LED blink program where one LED is toggled.

I use STM32CubeMX (version 6.1.0), STM32CubeIDE (version: 1.5.0), STM32CubeH7 Firmware Package (V1.8.0 / 29-May-2020), STM32CubeProgrammer (v2.6.0-RC3), ST-LINK FW : V2J37M26, HAL.

Also this LED program does not work on the suspicious boards. Instead of the LED toggling cleanly, there is rather a kind of flickering. This points again to a continuous resetting.

While debugging I noticed that already in the startup file something goes wrong. I try to describe the behavior:

  • Program counter starts in the Reset_Handler
  • Stack pointer is loaded
  • Asm cmd: bl SystemInit (branch to the function SystemInit()) (Picture1)
  • ! Does not jump to the function SystemInit()
  • ! But jumps into the IQR- Handler of the selected Timbase Source (e.g. SysTick Handler or TIM6_DAC_IRQHandler) (Picture2)

After that the program jumps around in some HAL_ functions and ends up in the Reset_Handler again.

This behavior can be observed on three boards. On the other boards the program counter jumps normally into the SystemInit() function and everything behaves normally. If the SystemInit() function is replaced, the same behavior occurs.

Concerning hardware:

The power supplies (VBAT, VDD, VSS, VCAP) seem to be ok. BOOT0 is connected with a 1K to GND. BOOT1 is not present(?). The NRST input is cleanly pulled high (3.3V).

I am attaching two screenshots of the program running. The first picture shows the pc in reset_handler. Sp, lr and pc registers appear normal. If you go a step in debug mode, the pc jumps to a wrong position.

Also I add the Project "BlinkTest".

Has anyone of you ever had such a behavior? Or can someone give me a hint where to look for the error? I run already out of ideas.

Thanks for your feedback

Elena

1 ACCEPTED SOLUTION

Accepted Solutions
Ekowa.2
Associate II

I found the solution. Actually I had the same error as in the description here:

https://community.st.com/s/question/0D53W00000CPohe/stm32h743-iwdg-continuously-reset-mcu

In my Code the IWDG is not activated. But if the hardware control is selected it will get activated automatically.

Somehow the option bytes in ST Link Utility getting modified sometimes. Still do not know exactly why.

Thank you all for your effort!

View solution in original post

10 REPLIES 10

That's not one single step between the two screenshots, as several registers have changed.

Try single-stepping in disasm and observe what's going on. I don't know how this works in Cube, I don't use Cube.

JW

Ekowa.2
Associate II

Hi JW,

thank you for your answer. It is actually only one single step (Step Into).

Elena

TDK
Guru

Clearly more has happened between the two screenshots than just a single instruction. One possibility is the watchdog has reset the chip, which would explain the result.

In any case, since the chip has reset and that is part of the behavior you're debugging, read the RCC->CSR register to determine the cause.

Look at the VECTACTIVE bits to determine what interrupt the CPU is in.

If you feel a post has answered your question, please click "Accept as Solution".

> It is actually only one single step (Step Into).

That's probably "source" step. You need to step in disasm.

@TDK​  or anybody else versed in CubeIDE, can you please comment on this particular detail?

JW

"Instruction Stepping Mode" can be enabled with this toggle. When enabled, the "Step Into (F5)" will single step through assembly code. When disabled, it single steps through source code.

0693W00000GY5EeQAL.png 

I think something else is going on here though.

If you feel a post has answered your question, please click "Accept as Solution".
Ekowa.2
Associate II

Thank you both for your ideas. I'll work on it on Monday and will give feedback.

Sounds like a short, or something causing a POR / Brown Out

Perhaps scope NRST and see if that triggers, and if a small delay loop at the head of Reset_Handler can push out the time to reset cycle.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Uwe Bonnes
Principal III

I had similar problems when I overclocked the device by accident and with to few waitstates.

Ekowa.2
Associate II

I found the solution. Actually I had the same error as in the description here:

https://community.st.com/s/question/0D53W00000CPohe/stm32h743-iwdg-continuously-reset-mcu

In my Code the IWDG is not activated. But if the hardware control is selected it will get activated automatically.

Somehow the option bytes in ST Link Utility getting modified sometimes. Still do not know exactly why.

Thank you all for your effort!