STM32L5 lockup, Pulling nRST to GND does not reset

[MLint.1]

STM32L562

I have the IWDG set up to fire 4 seconds if no HAL_IWDG_Refresh(&hiwdg) is executed.

Very occasionally, a lockup condition occurs.

But the STM32 does not reset.

Moreover, grounding the nRST pin does not reset the STM32

Scoping the nRST pin, i can clearly see the IWDG pulsing the pin, But the STM32 does not reset.

Only a power cycle resets..

nSRT pin is connected to a 100n cap, nothing else, as per the manual.

I am all out of ideas, here

Help Please!

[TDK]

What behavior are you seeing that leads you to believe it's not resetting? Could it be stuck in initialization code?

If you debug and hit pause when the problem happens, where is the code at?

[S.Ma]

Seems to be a cloned post here.

[MLint.1]

Thanks for responding.

Unfortunately, I cannot debug, as this happens only occasionally and randomly.

What makes me think that the MCU is not resetting is that the GPIO's are not in the correct state

following MX_GPIO_Init();

In main()

usual init routines etc.

After init, a printF function sends boot up welcome etc text to a uart

I then have a main loop which times various events, then after those events have completed, i put the STM32 into standby. A wake up timer or input to WKUP2 wakes from standby.

What leads me to think that the CPU is not resetting is:-

There are no outputs on uart, or indeed any activity at all on any ports, (except for a sharp -ve pulse every 4 seconds on the nRST line).

In MX_GPIO_Init(), i have , for example, configured PC13 configured as WKUP2 (input).

When the CPU locks, this port is driven HIGH.!!

PC13 is never configured as an output anywhere in the code.

Other pins that are configured as outputs, eg, to flash an LED, appear to be in a permanent tri-state.

In other words, the cpu appears dead.

Upon power cycle, i get the usual boot up message, LED flashing, and general port activity commensurate with normal running.

I had thought that somehow, the PC may be vectoring to the bootloader, and sticking there, but my BOOT0 pin is low, and besides, I clear the nSWBOOT0 option bit, so that PH3 is a GPIO.

Is there anything deep within the ARM cpu that can accidentally disconnect the nRST pin from the core "System Reset" line?

Any hints gratefully accepted.

here is snippet of the init from reset:

 

[TDK]

You set IWDG for 4s and you see an event every 4s. It seems likely that’s the cause of the event.
Nothing on this chip can disconnect NRST. That’s hardwired.
From you code, looks like you have persistent memory. Perhaps this is getting into a bad state and causing issues during startup. That would explain things.
To definitely see if the chip resets you could toggle a GPIO immediately upon reset within the startup code using direct register access.
You can also debug a chip that gets into this state by attaching a debugger and starting a debug session without flashing or resetting the chip.

[MLint.1]

Thank you for your interest.

"To definitely see if the chip resets you could toggle a GPIO immediately upon reset within the startup code using direct register access."

I will try that that.

In my startup code, I initialize 3 uarts, an SPI bus (to read an external flash chip) and an I2C device.

When the chip locks up (which is only once in a while) I see the nRST pulses, but no other activity at all on any other io. When locked, the current consumption seems higher than the normal run. (i am clocking all the main busses at 16MHz using the HSI)

And what is odd is that some pins are set as output high, conflicting with that set by MX_GPIO_Init();

This is what is leading me to think that PC is vectoring to some other block of code upon reset.

But i will try blipping an LED using direct port access, not using HAL.

I take note of your statement

"Nothing on this chip can disconnect NRST. That’s hardwired."

Thanks again.

[Danish1]

So you initialise I2C in your startup code.

What is the state of the I2C lines for a locked-up device?

It is possible for the I2C bus to lock up if the stm32 is reset during the time SCL is high but an external peripheral is driving SDA low.

When the stm32 comes up out of reset it will see SDA is low and assume I2C is busy (I2C supports multi-master operation). And wait. Forever.

The fix is, before you start calling HAL routines to initialise the I2C module, to clock-out whatever was going on on the I2C bus. Program SCL and SDA as open-drain GPIO. Then manually set SDA high and clock 9 pulses on SCL at 100 kHz square-wave. Then for good measure manually generate a stop-condition.

Only then can you be confident that the peripheral won’t drive SDA low so you’re free to initialise the stm32 I2C hardware by HAL calls or whatever.

[MLint.1]

Thanks..

"It is possible for the I2C bus to lock up if the stm32 is reset during the time SCL is high but an external peripheral is driving SDA low."

That is a distinct possibility!

I will check it out.

Regards,

m

[MLint.1]

Do bear in mind that the lockup scenario happens very infrequently, and is very difficult to create or find a unit that has locked up, whatever circumstances favour a lockup.

What is foxing me is the

It it possible for MX_GPIO_Init(); to lockup or fail in some way?

I ask this because when we find a unit that has locked up, I probe the pins and observe the following:

nRST H, -ve pulses every 4 seconds.

32kHz LSE crystal Buzzing ok.

All other pins static

PC13 Output High (WKUP2)

PB10 Output High

PA4 Output High

PA5 Low

This conflicts with how MX_GPIO_Init(); configures the above.

The only pin that should be high, is PA5, which is configured as an gpio input, with pull-up.

Other pins are configured as communication ports.

Attached is MX_GPIO_Init(); Its simple enough.

Regards,

m