2019-07-23 04:53 AM
I'm using STM32CubeMX 5.2.0
MCU: STM32L053R8Tx
Firmware: STM32Cube FW_L0 V1.11.2
Toolchain/IDE: MDK-ARM V5
Tested with 3 different boards, even with a default code (as generated by CubeMX) in debug mode, and also with a simple UART transmitter program (transmits a message every few seconds to check if the program is still alive) without the debugger.
2019-07-23 05:03 AM
can you pause the code and see where it is ?
check the call stack after a crash.
generally in a hardfault because you have filled a buffer beyond the ram space, or you have tried to write a read only register...
check what happens when the transmitter buffer become filled, where does the next byte go ? at the beginning ?
also check if the chip is getting hot, this would also stop it working after a short period.
2019-07-23 05:04 AM
Make sure the stack size is large enough, in Keil that would be in startup.s
Make sure you have a Hard Fault Handler that outputs useful information to the UART.
Check any other while(1) or spin loops it might get stuck in. ie Error_Handler()
2019-07-23 06:05 AM
> ...even with a default code (as generated by CubeMX) in debug mode, and also with a simple UART transmitter program ...
Your trust in Cube generated code is not really substantiated.
The long period tends to point to either a incorrect memory access like an array index overflow. or an interrupt - related race condition.
Perhaps nested interrupts that overflow the stack. Cube does a lot of stupid callbacks in interrupt context.
2020-01-22 04:53 PM
@elyes ,
did you find the cause of crash?
JW