About the occasional chip reboot and the top address of the stack being modified

[muke121]

The chip used here is STM32F205RGT6 and has the function of using IAP. BootLoader program is placed on 0x08000000,APP is placed on 0x08010000.

With a large number of devices using the same version of BootLoader and APP, occasionally a few devices will have two strange problems:

1.Some devices are constantly rebooting because the devices are running in different cities and can't find the same patterns. When testing, I found that I occasionally entered BusFault_Handler, UsageFault_Handler, and HardFault_Handler. We can't find the root cause

2.The same program, some devices run normally for a long time, and suddenly the top address of the stack on 0x08000000 after a power on is modified, resulting in failure to start normally. The address at the top of the stack should be 0x20004650 in normal circumstances, but 0x00000440 in the case of an exception.(This is shown in Figs. 1 and 2)

[TDK]

> Some devices are constantly rebooting because the devices are running in different cities and can't find the same patterns.

Not sure I understand. Why is running in different cities relevant? What patterns does it look for?

If devices are rebooting unexpectedly, verify power is valid. Look at RCC->CSR flags after a reboot to determine the cause of the reboot. Shouldn't be a mystery here. Write them out to a debug log which you can monitor or record.

Output your hard fault information so you can understand why the hard fault occurred and use that to track down the offending code. Be detailed here. There are many registers which tell you the exact cause of a hard fault, STM32CubeIDE has a hard fault analyzer. It doesn't have to be a guessing game.

 

> suddenly the top address of the stack on 0x08000000 after a power on is modified

If the actual data in flash is changing, something is writing it. Probably a bug in the bootloader.

Note that the value 0x20004650 can be changed to 0x00000440 by only changing 1s to 0s, which is possible in flash without an erase. There is no ECC on this chip to be able to detect a double-write.

I would take a look at the logic used to write to the flash. It is relatively hard to write to flash since it needs unlocked first. Should be able to track down the issue.