We have been working with both the RAK11160 and RAK3172 modules and have encountered a similar issue on both.
For the RAK11160, the module occasionally does not enter boot mode during firmware upload. In most cases, we can recover it by using the RAK Firmware Upgrade Tool to flash the factory firmware (rak11160_latest.bin). If that does not work, we use STM32CubeProgrammer over UART to erase the flash and program rak11160_latest_final.hex. After that, we are able to upload our application again from the Arduino IDE.
However, after repeating this recovery process multiple times over the course of development, the module eventually becomes completely unresponsive. At that point:
Our application no longer produces any output on the serial monitor.
The module cannot be detected by the RAK Firmware Upgrade Tool.
STM32CubeProgrammer is also unable to connect to the module.
We have observed a similar issue with the RAK3172. During development, we were storing application data in flash using api.system.flash.set(offset, buf, len). The write frequency was relatively low, so it is unlikely that the flash endurance limit was reached. Nevertheless, after some time, the module also became completely unresponsive and could no longer be accessed using either the firmware upgrade tool or STM32CubeProgrammer.
Has anyone experienced a similar issue with either module? Is there any known recovery method when the module is no longer detected by both the RAK Firmware Upgrade Tool and STM32CubeProgrammer, or could this indicate a hardware failure?
What RUI3 version are you using?
How is the power setup on your PCB for the two chips?
Is the power controlled by an host MCU or are you using the WisDuo modules as stand-alone MCU’s?
We had occasionally problems with failed flash writes that corrupts the internal settings of the module, in this case the device would be stuck and needs flash erase and re-flashing the firmware.
This usually happened when the device was powered down by a host MCU while it was still writing changed settings into its configuration in the flash memory.
As we cannot control the power supply in these cases, it cannot be avoided from our side. It has to be handled by the application on the host MCU.
If you are using STM32CubeProgrammer the SWD interface should always work. Eventually you need to connect the RESET as well.
If using STM32CubeProgrammer over UART, you need to connect the BOOT pin to VDD, issue an power cycle or reset before STM32CubeProgrammer can connect to it.
We are programming the chip using the usb-ttl converter over UART.
Yes, we can recover it from that state using the stm32cubeprogrammer, and then after erasing the flash memory completely, we flash RAK11160_latest_hex and after that it starts working fine.
But at one point, chip stopped responding, even stm32cubeprogrammer could not connect with it over UART, or SWD.
