Hello,
I had problems with a cople of RAK3172 in previously running systems which suddenly do not respond anymore to AT commands via UART and do not execute their program. The only way to reactivate them is connecting an ST-LINK/V2 interface using STM32CupeProgrammer and reloading the firmware. Even this is only successful when I perform a full chip erase before.
I suppose this has something to do with the boot mode which might be accidently enabled after a bouncing power source is connected or something like that. I use 10µ and 100n decoupling capacitors and 10k/100n at the RST pin as suggested.
What am I supposed to do with the BOOT pin? I left it floating. Is this correct?
Do you have any other hints how to avoid the problem?
Thank you for the answers.
I had version RUI_3.4.11_RAK3172-E. This is what the RAK Wireless Store shipped 6 weeks ago.
Can I be sure that the issue will be gone after updating with the latest version?
I was asking for the version because in the older versions was a feature to enter bootloader mode on a double reset signal. This was working well when used as a WisBlock Core module (Reset connected with R/C combination to a button), but caused problems with bouncing reset signals on custom boards.
It is removed since V3.5.x, which I don’t recommend to try, all the V3.5.x are beta and have problems.
V4.0.0 fixes a lot of problems and I am using it now on all my RUI3 devices.
For the BOOT pin, we leave it open in our reference design and on the RAK3172 Evaluation Board and it causes no problems.
The RESET pin should be connected to a R/C combination as shown in the reference design ==> RAK3172 Breakout Board
Latest firmware versions and changelog are in our Download Center