RAK3172 latest firmware with unresponsive "boot mode"

Hi, I am using a RAK3172 module on a custom PCB and am having an issue with the latest firmware release for this module.

The RAK module was working perfectly when using the old 1.0.4 firmware, however I wanted to use some commands from the RUI3 protocol.

Now seemingly randomly the device enters a mode where it sends <.BOOT MODE> over UART2 on powerup. When in this mode, the module is completely unresponsive. This occurs when the Boot0 pin is floating or when it is grounded. I can also force entry into this mode by sending the AT+BOOT command while the module is still being responsive.

Here’s an example of what is being sent from the device:

The module will stay in this mode even during reset or powering on/off

While in this “boot mode” STM32CubeProgrammer cannot communicate with the module:

The only way I have found to exit this mode is to tie the Boot0 pin to 3V3. When doing this, the device stops sending <.BOOT MODE>, and can connect to the programmer:

From here I have to flash a new version of the firmware from the file RAK3172-E_latest_final.hex using the programmer connected over UART. Once I do this the module returns to a usable state for a small amount of time, but then eventually returns to <.BOOT MODE>.

Is this a bug with the firmware, or an error in my processes?

Welcome to RAK forum Sam.

You can only connect to STM32CubeProgrammer via UART if BOOT pin is pulled up (3.3V).

Boot mode will only happen if you perform double click on reset button. If only in power up, is the supply voltage stable during this power up process?

Afternoon Carl,

Thank you for your prompt reply. We are developers for a big customer that has already ordered a large amount of RAK3172 units, we are moving to this unit from the 4270 due to its LoRaWAN certification status.

We have received samples of the RAK3172 to quickly approve the design but they came with the old software (v1.0.4) and after upgrading to the new RUI3 we are experiencing this issue.

We checked the reset line and it does bounce when the unit turns off, we will work on a solution for this issue.I would appreciate if you could answer the following:

Question 1: Is the update to RUI3 required for the module to be LoRaWAN certified (and pass the certification test)
Question 2: Once in BOOT mode it only comes out of it if we actually flash new code, is there an alternative?


Hi @Samd ,

The issue is caused by the bounce on the reset pin. Is there a way to remove it? Right now, RUI3 bootloader was designed to be like that so that user has the ability to recover a firmware via double-click on reset.

To answer your questions:

  1. RAK3172 legacy and RUI3 firmware shares common RF related stack. Only the exposure of APIs is the major improvement. I am not sure with what you mean with LoRaWAN certified. Is it the LoRa Alliance certification or others like CE, FCC, etc.?
  2. Right now there is no way unless to flash a new code. I am coordinating now to the SW team on possible work arounds if any.

Hi Carl,

We are referring to the LoRaWAN Alliance Certification.


Hi @Samd ,

I am still coordinating with our Certification Team about the LoRa Alliance Certification just to be sure.

Regarding your issue on boot mode, I’ve sent you a message directly.

I have a similar issue when flashing with ST-LINK.

For some reason I could not use “RAK Device Firmware Upgrade Tool v1.4” anymore. I had three RAK3172 Modules that simply hung. So I thought that I would try to flash them with ST-LINK and found that after flashing completed the modules only responded with “<BOOT MODE>” and nothing helped.

So I decided to flash those modules with ST-LINK with firmware “RAK3172_v1.0.4_Boot+App_20220218.hex”. That worked. The modules started to respond again and behave as expected with the following banner.

LoRa (R) is a registered trademark or service mark of Semtech Corporation or its affiliates. LoRaWAN (R) is a licensed mark.

______  ___   _   __  _    _ _          _               
| ___ \/ _ \ | | / / | |  | (_)        | |              
| |_/ / /_\ \| |/ /  | |  | |_ _ __ ___| | ___  ___ ___ 
|    /|  _  ||    \  | |/\| | | '__/ _ \ |/ _ \/ __/ __|
| |\ \| | | || |\  \ \  /\  / | | |  __/ |  __/\__ \__ \
\_| \_\_| |_/\_| \_/  \/  \/|_|_|  \___|_|\___||___/___/
RAK3172-H Version:v1.0.4 Feb 18 2022
Current Work Mode: LoRa P2P.

After that I tried to flash with “RAK Device Firmware Upgrade Tool v1.4” again and upgraded to “RAK3172-E_3.2.0-p2_22q1_final.87_latest.bin” and then further to “RAK3172-E_latest.bin”.

Now the modules are working as expected showing the new banner.

RAKwireless RAK3172-E Example
Current Work Mode: LoRaWAN.

Something seems to go wrong when flashing with ST-LINK. With ST-LINK only Firmware v1.0.4 is successful. Firmwares v3.2.0 and v3.4.2 render the modules unusable either just hanging in a unidentifiable state or stay in “<BOOT MODE>” without any chance to exit.

I just leave the RESET pin floating (not connected) unless the module is connect to ST-LINK.

So, it seems to me that there is something going wrong when flashing with ST-LINK. Why does it work with v1.0.4 but not with v3.2.0 or v3.4.2? I tried to follow the documentation here (STM32CubeProgrammer Guide for RAK Modules | RAKwireless Documentation Center) as close as possible. But it did not work. What is the problem?


Hi Thomas,

On the latest RUI3 firmware, we have an implementation of enabling boot mode by double clicking (pulling to GND) the reset pin. This causes the Boot Mode. To leave boot mode state, you have to execute at+run command.

Hi Carl,
Thanks for your reply. I will try again. Maybe I missed something. I was not successful with at+run yet. But let me double check first. I’ll let you know.

1 Like

Apparently the at+run<CR><LF> to exit Boot Mode needs to be lowercase… different from all other AT Commands on the RUI3 :wink:

1 Like