STM32G474: Processor hanging when NVIC_Enable Debugger-Timer IRQ.

[seppeltronics_v]

Hello,

currently I'm transferring from a Nucleo to the target electronics(STM32G474RE3), but when I download the Code(verified successfully) and start it, the Processor is hanging when the Timer IRQ for the Debugger is enabled.

• Supply Voltage is ok, 3.3V
• NRSET is at 3.3V
• Signals on SWDIO and SWCLK look ok(square)

I really have no idea what the issue is, it works on the Nucleo, but it can't get passed that Code.

I'm really running out of ideas, has anyone had these issues before or an idea what the issue may be. The debugger just can not get forward, it's stuck and if I start the controller in standalone, it will not start driving the resonator, driving I2C-Lines,.. nothing.

Thank you everyone in advance for helping.

Best Regards, Seppel

 

 

[TDK]

It's stuck in an interrupt handler. To see which one, hit play, then hit pause, then examine where the code is or the VECTACTIVE field within the SCB registers.

Perhaps you have an interrupt which fires more often that it can be processed, or you are failing to clear a flag within the IRQ so it repeatedly fires.

[Bob S]

Your first images shows the PC at 0x1fff5064 after the interrupt. That is in ST's bootloader area (or certainly NOT in user-programmable FLASH). Check your BOOTx pins (I don't recall if the G4 has BOOT0 and BOOT1 pins). Check your vector table contents. And what @TDK​ said about checking which vector is active.

[EDIT] Also check your SP - if it points somewhere non-sensical that could be another inidcator of "infinite interrupts/stack overflow".

[seppeltronics_v]

Hello @Bob S​ , Hello @TDK​ ,

• The Boot-0 (Boot-1 does not exist, as far as I'm aware, checked the Nucleo schematics) is open(Testpad), just like the Nucleo.

The difference between the Nucleo and the target is that the target is a 125°C variant:

• Nucleo: STM32G474RET6U
• Target: STM32G474RET3

What is interesting, if I have a brakepoint before __STATIC_INLINE void __NVIC_EnableIRQ(IRQn_Type IRQn) and the use the debugger in "Step Into"-Mode, I get passed it, return even into the fuction HAL_InitTick() , but then the Controller get's stuck at the Codeline HAL_NVIC_SetPriority(TIM1_UP_TIM16_IRQn, TickPriority, 0U);

• The Stackpointer is at 0x2001ff48 (RAM)
• The Program Counter is at 0x1fff5064 (Flash, system memory or SRAM, depending on BOOT configuration)

@TDK​, what do you mean by the "VECTACTIVE field within the SCB registers"

Thanks a lot for the awsome help so far, did not solve the issue, but with every step I get closer.

Best Regards, Seppel

On the Nucleo the Pin is open, Jumper not set, like on my target-board

 

The Memory layout:

[seppeltronics_v]

Hello,

did a Pulldown of Boot-0 to GND, works!

I have a 2nd STM32G474 Nucleo, the Jumper is also not set, works as well. I can not explain why, if someone knows, please tell me.

Thanks a lot, best Regards, Seppel

[TDK]

If BOOT0 is floating you will have unpredictable behavior unless BOOT0 is overridden in the option bytes. See what they are on each board using STM32CubeProgrammer and adjust accordingly.

Your screenshots suggest the TIM16 update interrupt is firing, but the handler is not correctly set in the vector table. Probably CubeMX doing something screwy on boot to not properly set it. I doubt it's solely a BOOT0 issue, as the execution is clearly within user code until the interrupt handler. BOOT0 being high can't explain that.

[seppeltronics_v]

Hello @TDK​  ,

ok, interesting, so it may have been pure luck on the Nucleo Demo-Board? Or is it booting into the Bootloader and getting Data from the On-Board ST-Link, which I would think is un likely.

I agree, it starts in the main, as the stacktrace that the debugger retrieved indicates, but it then ends up somehere. Is there a second Interrupt-Table, or is there only one? I would assume the ISR address is set before the IRQ is enabled, so there may be two options

1. The ISR Address is overwritten in the vector table
2. There is another vector table

Do you have any idea how to find that out?

Best Regards, Seppel

[seppeltronics_v]

P.S. Do you know how to set the Option-Bytes to the Boot from the Bootloader is deactivated, or could you tell me where that is documented nicely?

[gbm]

Surprise! It's not documented in the Bible nor in Harry Potter, but in the Reference Manual for your MCU. Who could expect it? 😉 Anothe surprise: to find it, you could read a section on Flash or search for... no, not ice creams but... option bytes! 😉

[TDK]

There is only one interrupt table.

> I would assume

Don't assume. Verify.