Unknown pulsing on STM32L073RZ

[Adam Mitchell]

Hi there,

I'm working with an STM32L073RZ CPU and Mbed OS 5.12.0 and experiencing an issue that I'm not quite sure how to describe. The processor gets into a state whereby it oscillates a pin (PA_5 which is setup as an InterruptIn that pulls down) and also has periodic power spikes that are inversely correlated to the state of PA_5 - this can be seen in the image below. As soon as this issue occurs the CPU seems to no longer be responsive, suggesting that it has crashed.

I am working on a custom board, but I've verified that this issue occurs on a Nucleo-L073RZ development board too.

At first I thought that I may be running out of memory as the issue seemed only to occur when manipulating strings (as, unfortunately, I need to serialise to JSON). However, monitoring memory usage with the API provided by Mbed shows that I am using only a fraction of available memory.

The issue has also occurred when attempting to read an integer via scanf from a hardware UART that is connected to a SIM800 modem.

Both causes seem to be string manipulation related but I'm really not sure what else to check aside from memory usage.

Any insights are greatly appreciated.

[Tesla DeLorean]

Does your Hard Fault handler output anything helpful? Make sure it and things like Error_Handler() output entry warnings

https://www.st.com/resource/en/datasheet/stm32l073rz.pdf

PA5 is specifically called out with respect to current injection susceptibility.

[Adam Mitchell]

There’s nothing from the hard fault handler, or any error handler, unfortunately - no UART output at all. Can’t even connect over SWD due to some bugs with ST-Link Utility.

I wouldn’t be totally surprised if there was current injection on the custom board, but on the dev board the pin is simply broken out as a GPIO.

[Tesla DeLorean]

For this sort of thing you'd probably want to ping your local FAE, probably a known issue

[Adam Mitchell]

Figured this out in the end - I was running out of memory. I'm not quite sure where as Mbed's memory management API reported a fair amount of available memory. Alas, adjusting heap/stack sizes and some creative scoping fixed the issue.