2025-01-28 02:43 AM
Dear ST Community,
I have been working on the firmware which contains the AT commands modem, Winbond flash memory. After some time I have relised the microcontroller is automatically getting restarted/. I had doubt on the hardware then we have redeveloped the complete hardware from known pcb designer, but again we are facing the same problem. I have printed the stack details also but not able to find the following issues:
1. Stack overflow.
2. Buffer overflow.
3. dereferencing unassigned memory.
4. power supply issues.
The restart is so random so that we are not able to understand and figure out the section. Also the PC shows the random values.
Thanks and Regards
Sachin Verma.
2025-01-28 03:44 AM
I think you need to reproduce the behavior at your desk / lab.
Then, check the RCC CSR register. Here a snapshot from the F40x manual :
And here a list of reset causes, from the same manual:
You don't have a watchdog activated in your firmware, do you ?
2025-01-28 04:05 AM - edited 2025-01-28 04:11 AM
Welcome to the forum.
For best results, please study How to write your question to maximize your chances to find a solution; some more details would help:
@sachinVerma wrote:the AT commands modem, .
What "AT commands modem"?
Please post the board schematic.
@sachinVerma wrote:not able to find the following issues:
So what tests have you done in an attempt to find those issues?
If your "AT commands modem" is a GSM (or any other radio) device, remember that these have very "peaky" current draw - the peaks demand careful power supply design, and can easily cause problems like "brown-out".
As @Ozone said, your can read the reset reason.
Do you have a watchdog enabled?
Instrument your code so that you can see what's going on.
PS:
Some tips here on instrumenting code so you can see what's going on without intrusive debugging:
Some tips on debugging in general:
#InstrumentCode
2025-02-04 11:16 PM
Hello Andrew,
Thanks for responding fast on the query, I have checked the MSP, HFSR, BFAR, CFSR
1. Yes I have enabled the WDT in the system for 8 seconds and that is also getting refreshed in the systick interrupt. So firmware sometimes works for 5 minutes then restarts or in sometimes it just restarts after 20-30 minutes initializing the program in some devices. Some of the device are working perfectly fine on site but some are not sending data at all. After site visit we have found out that the controller is never able to perform the data polling cycle, it is getting restarted before that.
2. I have checked the power lines of controller form oscilloscope but found no drop/rise in the power so that controller may get restart or damaged.
3. This are the values of RCC->CSR=0x0E000003, 0x3E000003, 0X2E000003 I am getting.
4. I have disabled the cache for find out the correct value of PC, but the values are always random.
5. I have also covered all the cases of the buffer overflow in the firmware so that the buffer should not happen in any case.
6. I am using internal RC oscillator as the clock source.
Please find the power supply design.
debug message1 :
Hardfault occured!, HFSR = 40000000, CFSR = 20000, BFAR = E000ED38, DFSR = 0, AFSR = 0
REGISTER CONTENT>
R[0] = 20000660, R[1] = 80 , R[2] = 0, R[3] = A R[12] = 1, R[lr] = 8014735, R[PC] = 40, R[MSR] = 20000000.
--------------------------------------------------------------------------------
debug message 2:
MSP=0x2000FD18, PSP=0x0
Hardfault occured!, HFSR = 40000000, CFSR = 8200, BFAR = 2B036977, DFSR = 0, AFSR = 0
REGISTER CONTENT>
R[0] = 2000FF2C, R[1] = 2000FF2C , R[2] = 4302B06C, R[3] = 2B036978 R[12] = A1, R[lr] = 801A015, R[PC] = 801A576, R[MSR] = 21000000
Thanks and Regards,
Sachin Verma.
2025-02-04 11:28 PM
I would highly recommend this document from Keil (now part of ARM) when dealing with faults.
2025-02-05 12:56 AM - edited 2025-02-05 12:57 AM
Have you looked at the Reset Cause - as shown by @Ozone ?
@sachinVerma wrote:debug message1 :
Hardfault occured!, Verma.
So, as @Ozone said, you need to debug that Hard Fault.
Here are some more tips on debugging Hard Faults - both Cortex-M in general, and STM32 in particular:
BTW:
@sachinVerma wrote:1. Yes I have enabled the WDT in the system for 8 seconds and that is also getting refreshed in the systick interrupt.
That's a very poor way to manage a watchdog!
The whole point of a Watchdog is to catch cases where your code execution gets "stuck".
Interrupts can continue while your main code is "stuck" - so just refreshing the Watchdog in an interrupt handler rather defeats the object of the Watchdog!
2025-02-05 01:09 AM
@Andrew Neil wrote:That's a very poor way to manage a watchdog!
The whole point of a Watchdog is to catch cases where your code execution gets "stuck".
Interrupts can continue while your main code is "stuck" - so just refreshing the Watchdog in an interrupt handler rather defeats the object of the Watchdog!
That was the legacy code which I have changed, After changing the this watchdog issue is still there.
2025-02-05 01:11 AM
Thanks Ozone ( lead II) for providing the document.
I have gone through the document but I have not found any issue that is always occurring due to same reason every time. the restart of the mcu is random.