Module RAK3172 + RUI3 4.2.0 dead

Dear Coleagues,

I am facing a critical problem with the RAK3172 module.

Two modules seem to be dead, no activity in the UART2 serial port… No response for AT commands, no connection to the WistoolBox, even no startup messages during power on.

The module was working with an older FW. I updated the FW to the latest RUI3 4.2.0 and did some initial parametrization (DEVEUI, APPKEY, RXdelays, Low Power mode, etc…, all via AT commands.

AT VER=? confirmed the latest firmware, and all AT commands for the parametrization were successfully processed.

After a reset the problem happens… zero communication via serial port!

In the first board I thought I did something wrong in the hardware connections and damaged the module… than I tried a second board and the same problem repeated.

The FW running in the host controller is working, no issues detected so far.
Follow the circuit diagram showing the RAK3172 connections.

Some questions:

Is it possible to “kill” the module via AT commands?
Any change on the new FW RUI3 4.2.0 which could lead to this dead condition? Any know bug?
Is there a way to flash an older firmware or other method to confirm if the module is still working?

Thank you.

What was the “older” firmware version?

Just guessing, if your “old” firmware was V1.0.4, the baud rate changed from 9600 Baud to 115200 Baud.
Other changes between V1.0.4 and RUI3 can be found in AT Command Migration Guide of RAK3172 to RUI3

If your “old” firmware was already RUI3, how did you flash the new firmware? Are you sure the flash process finished successfully? If not, the module is in bootloader mode and does not respond to AT commands other than AT+VER=? (will display the bootloader version) and AT+RUN

Hi @beegee ,

The previous version was already RUI3, 4.1.0.
The flash was done via UART2 using the WistoolBox.

Sure, the flash process was completed and the module was working. All the AT commands for the initial configuration was precessed and repplied OK.

Isolating the host controller and using a serial terminal on UART2 does not work as well… no messages at all.

For the moment I just have the new FW 4.2.0 as a variable…

Shoud I try to flash an older FW via STM32Cubeprogrammer? Or do you suggest any other procedure before doing that?

I have multiple RAK3172 and I am switching very often between RUI3 versions and I never saw a problem after flashing V4.2.0.

Instead of flashing an older RUI3 version, I would try to flash the HEX file for V4.2.0 with STM32CubeProgrammer.

Hi @beegee ,

Using the STM32CubeProgrammer I tried to flash the HEX file for V4.2.0:
https://downloads.rakwireless.com/RUI/RUI3/Image/RAK3172-E_latest_final.hex

First I performed a Full chip erase before starting the programming.

For the V4.2.0 the file download is completed but in every attempt there is an error during verification! And the module does not work.

420 error 1

For the V4.1.0 and V4.1.1, flashing is completed and no error during verificarion. Module is back to live, working.

After this I tried again to flash the V4.2.0 and still failing during verification.

For the moment I will continue my project with the V4.1.1 until we find what could be the root cause.

Please, share your thoughts.

Did you try to download a fresh copy of the V4.2.0 files?

Hi @beegee ,

to confirm I did a fresh download of the same V4.2.0 file.
First try it failed again in the verification step.
Repeating the process it was possible to conclude the flashing with verification passed. (It should pass in the first time!)

Initially I had some dificulty to connect the STM32CubeProgrammer. I reduced the C207 from 100nF to 10nF and it worked better.

But, the big question for me is why two boards went to this dead state, using AT commands only!? There must be some explanation.

I will test more to see if the problem will repeat.

According to STM32WLE5 datasheet there is an internal permanent pull up in the RST pin. Maybe my extenal pull up is too much… will test removing it.

1 Like

@beegee ,

UPDATE - After less than 2 hours testing the problem happened again. The external pull up resistor was removed. This time I have logged the serial line.

Initial module configuration, right after FW updated to V4.2.0, this is done only once:
ATR
AT+ATM
AT+BAUD=115200
AT+NWM=1
AT+BAND=12 (My location is Brazil)
AT+NJM=1
AT+ADR=1
AT+PNM=1
AT+LPMLVL=2
AT+LPM=1

Board switched on, and the sequence bellow was communicated between host controller and RAK3172:

As the JOIN failed the application on host controller resets the RAK3172 and expects the startup message, to start again from a new JOIN command. But, as the RAK died, there is no more answer…

There might be something strange with de V4.2.0. This problem never happened with the previous versions…

Just guessing for a possible reason:
Can you confirm the Band 12, for LA915 region, was properly considered in this latest firmware with LoRaWan Stack 1.0.4?

For the join issue, you may want to check the events in Chirpstack / TTN.
It may due to other issues (incorrect keys, invalid DevNonce…)

Hi @IoTThinks ,

I am not that close to a gateway, from time to time the first JOIN fails… it works in the next try.

1 Like

Hi @beegee ,

anything new on this topic?
I just saw now a new topic using the same configuration (RAK3172 and LA915 region), complaining about possible crash.

Thank you.

Only suggestion I have is to go back to RUI3 V4.1.1

LA915 is very difficult, we do not have gateways that support these region, so we cannot really test much.

Hi @beegee , just to inform you.
About a week running the previous version: RUI3 V4.1.1, no issues.

I will follow the next releases, looking for a fix in the V4.2.0.