How to Update AT Command Version on RAK3172 and Use AT+SN=?

[Prasanna (Prasannaraj)]

Hi all,

I have two RAK3172 modules with different AT command versions and serial number access:

• Module 1:
  • AT command version: v1.5.13
  • Serial number is available with AT+SN=?
• Module 2:
  • AT command version: v1.5.11
  • Serial number is only available with AT+DEVEUI=? (no response for AT+SN=?)

Questions:

1. How can I update the AT command firmware version on my RAK3172 module (from v1.5.11 to v1.5.13 or latest)?
2. After updating, will AT+SN=? work the same on both modules?
3. Is it possible to change or update the serial number, or is it locked to hardware?

If anyone can share the correct firmware files, upgrade procedures, and clarify the difference between these serial number commands, it would be a big help.

[beegee (Bernd Giesecke)]

Welcome to the forum @Prasanna

AT+SN is read only and returns a serial number written during production. It is not a hardware serial number. After a chip-erase (e.g. with STM32CubeProgrammer or with Jlink), the SN is empty.

On a RAK3172 it is better to use AT+UID=? which returns the hardware UID of the STM32WLE5.

AT+UID is not available on older RUI3 versions and it is only available on RAK3172

To update to the latest RUI3 firmware for RAK3172, please check our Upgrade the Firmware guide.

Latest RUI3 version is V4.2.1.
The version numbers you listed in your post are the CLI versions, not the firmware versions.

[Prasanna (Prasannaraj)]

Thank you for your feedback.

I have updated all my RAK3172 modules to firmware version V4.2.1. I am operating them in P2P mode.

• On some modules (AT command version 1.5.13), the AT+SN=? command correctly returns the serial number (for example, AC1F09FFFE1CF98B).
• However, on other modules (AT command version 1.5.11), the same command AT+SN=? just returns OK without showing the serial number.

I understand that the AT+DEVEUI command is available in LoRaWAN mode, but not in P2P mode.

My application first reads the serial number to identify the LoRa module before starting communication. Is there any way to reliably get the serial number for all modules in P2P mode?
The serial number I am looking for (e.g., AC1F09FFFE1CF98B) is also printed in human-readable form on top of the module.

Any option or workaround to retrieve the serial number in P2P mode for all modules would be very helpful for my application.

Thank you in advance!

[beegee (Bernd Giesecke)]

If you updated ALL your RAK3172 to the latest firmware, there cannot be different CLI versions. RUI3 V4.2.1 has CLI version 1.5.14

> at+cliver=?
AT+CLIVER=1.5.14
OK
> at+ver=?
AT+VER=RUI_4.2.1_RAK3172-E
OK

As I wrote above, use AT+UID instead. It gives you the real hardware ID of the RAK3172WLE5.

[Prasanna (Prasannaraj)]

Hi, thank you for your feedback.

I have now erased all flash memory and programmed the new firmware version V4.2.1 on my RAK3172 modules. After updating, I confirmed that AT+CLIVER=? returns 1.5.14, as you mentioned.

Initially, AT+DEVEUI=? returned 000000.... I then wrote the correct DEVEUI using AT+DEVEUI=... while in LoRaWAN mode. However, since I am using P2P mode for my application, I found that entering AT+DEVEUI=? gives “AT MODE NO SUPPORT,” and AT+SN=? simply returns “OK” (without showing the serial number).

You suggested using AT+UID. I tried this command and it returns the unique hardware ID. Thank you for this suggestion.

Just to confirm:

• Is there any way to get the human-readable serial number (SN) in P2P mode (for example, the same value printed on top of the module)?
• Is there any command to write or modify the SN using AT commands, or is it factory-set and read-only?
• For my application, I would prefer to identify modules by this serial number rather than the UID if possible.

If there is any workaround or suggestion to achieve this, please let me know. It will really help with my application.

[beegee (Bernd Giesecke)]

AT+UID works in LoRaWAN and LoRa P2P mode.

The serial number is created and written to flash in our factory.
You cannot write it.
It is erased on a full flash erase and stays empty after that.

I don’t understand why you don’t want to use the UID. It is an unique ID of the MCU and the safest way to get a unique identifier.

[Prasanna (Prasannaraj)]

Thank you for the clarification.

I understand now that the SN is factory-programmed and gets erased during a full flash erase, so it cannot be rewritten or recovered afterward.

The reason I preferred using the SN is because we use two modules in the same product, and the human-readable serial number printed on the module makes it easy for us to physically identify and debug hardware or software issues. Our application code was already using the SN for identification, so it matched with what’s visible on the hardware.

Since the SN is no longer available after a full erase, I will update our application code to use the UID instead, as you suggested.

If there is any option to write the serial number using the AT+SN command, and you are able to disclose it, I would appreciate it if you could let me know privately. If there is no such option or you cannot share this information, no problem—I will update my whole code to adopt the UID method.

Thank you again for your support.