We are seeing an increasing number of field devices running legacy firmware v1.0.3 that stop responding. After evaluating several RAK3172 modules, we found that STM32CubeProgrammer cannot read address 0x08004800—reads to all prior addresses succeed, and reads after that region also succeed. Reviewing the bootloader binary suggests a “double click to enter boot mode” mechanism that erases that flash location to detect a double reset. If the flash at that address is worn out from excessive erase/program cycles, the bootloader appears to fail to start the application. Our deployed devices are power-cycled 100 or more times per day, so with the STM32WL rated for only 10 K erase/program cycles, they could hit the endurance limit in as little as 100 days.
Can you confirm that the double-click-to-enter-boot-mode feature works as it appears, and that this address is erased/programmed as frequently as it seems? It would also be helpful if we could review the bootloader source code to better understand the behavior and diagnose why our devices are failing.
There is no “double click to enter boot mode” on our RAK3172, neither on the (out-of-maintenance) old firmware V1.0.3 nor on the new RUI3 V4.2.x
Why do you need to power cycle 100 times a day? seems excessive. But a reset/power-cycle would not trigger any writing to flash. At least on RUI3, not sure about the old firmware.
