2019-06-24 10:25 AM
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.
2019-06-24 11:33 AM
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.
2019-06-24 12:14 PM
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.
2019-06-24 01:52 PM
For this sort of thing you'd probably want to ping your local FAE, probably a known issue
2019-07-12 04:13 AM
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.