Module RAK3172 + RUI3 4.2.0 dead

[IGtti (Iaran Gadotti)]

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.

[beegee (Bernd Giesecke)]

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

[IGtti (Iaran Gadotti)]

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?

[beegee (Bernd Giesecke)]

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.

[IGtti (Iaran Gadotti)]

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.

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.

[beegee (Bernd Giesecke)]

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

[IGtti (Iaran Gadotti)]

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.

[IGtti (Iaran Gadotti)]

@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?

[IoTThinks (IoTThinks.com)]

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

[IGtti (Iaran Gadotti)]

Hi @IoTThinks ,

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

[IGtti (Iaran Gadotti)]

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.

[beegee (Bernd Giesecke)]

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.

[IGtti (Iaran Gadotti)]

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.

[IGtti (Iaran Gadotti)]

Hi @beegee ,

I see there is a new firmaware release, 4.2.1. But, on the release notes I could not find anything related to the LA915 issue.
Please, can you confirm this was really not treated in these update?

I guess the problem is only in the LA915 region…
In case I set AU915 and change the RX delays, and may be other parameters… would that be the same as LA915? Please, give me some indication on what to do.

Thank you,
Iaran

[beegee (Bernd Giesecke)]

Correct, we did not investigate into the LA915 problems.
I do not know how to change AU195 to work as LA915.
The whole LA915 support was implemented by supporters, not by us.

[IGtti (Iaran Gadotti)]

@beegee ,

What can we do to have an official review/release for the LA915?
Otherwise users of the public network in Brazil will have to keep using the old FW 4.1.1.

Here is the LA915 content:
https://ns.docs.everynet.io/channel_plans/LA915A.html

Or, at least point where in the code this configuration is implemented.

Thank you.

[beegee (Bernd Giesecke)]

We cannot test LA915, we do not have gateways or LoRaWAN server that supports it.

LA915 is a unofficial LoRaWAN region only supported by Everynet (afaik).

RUI3 is open source and its code is published in our Github repo ==> GitHub - RAKWireless/RAK-STM32-RUI: RUI3 BSP for RAK3172 modules

[IGtti (Iaran Gadotti)]

Unfortunatelly I do not have the knowledge of your system to perform this kind of debug.
I believe the issue should be simple, since it is working on the FW 4.1.1. Maybe some parametrization conflict after the introduction of the stack 1.0.4.

Please, do you have the contacts of this “supporters” who implemented the LA915?

[beegee (Bernd Giesecke)]

Not sure if I remember, it was in one of these posts:

RAK3172 Difficulty joining

My problem is that we have neither gateways nor a LoRaWAN server that supports LA915, so it is difficult to test and check what the problem could be. +EVT:JOIN_FAILED_RX_TIMEOUT Means that the device didn’t receive the JOIN accept message from the LNS within the two RX windows. What you can try is to change the join delay 1 and 2 with the AT commands AT+JN1DL/ AT+JN2DL commands. The message combination 19:13:19.178 → Receiving MLME_JOIN 19:13:19.223 → DevAddr:00000000 means that the devic…

LA915A on RAK3172

Wow, Sorry that you answered 2 months late. Then I canceled to use rak sdk and I rebuild the stm32 sdk to port la915, version loramac 1.0.4 But, please, wich rak wireless at version firmware did you use ? And exactly wich sequence did you use ? Did you try the everynet la915 certification software?

RAK3172 crashing

Hi, @beegee We conducted the same test using the same code, but compiled with versions 4.2.0 and 4.1.1. With version 4.2.0 and ACK disabled, the hardware does not crash. However, with version 4.1.1 and ACK enabled, the device crashes. The dev board we are working with has an LED on the SWCLK pin. The device sends a message with ACK and retry every hour to the LNS. When the device crashes, the LED stays ON at half brightness, similar to when the device is in BOOT mode. This is the last message…

RUI3 urgently needs a configuration for LA915

We are having several problems when using the AU915 on the Brazilian network (Everynet LoRaWAN) configured as LA915. Although the LA915 is based on the AU915, the LA915 is slightly different as can be seen at LA915 · Everynet Network Server Among the problems are: ADR malfunction, incorrect number of channels, it is not possible to deactivate the uplink and downlink dwell time, among others. Please, is it possible to include the LA915 definitions in the next RUI build? ASAP! https://ns.docs.…

[tcpipchip (MIGUEL ALEXANDRE WISINTAINER)]

Hi, @beegee @IGtti

I tested in Brazil the LA915…but…with STM32LoRaWAN and STM32CubeIDE…

I had to change two files…la915.h and la915.c

I spent 9 weeks to make it work.

I can sent you those files, if you want…