How to update the RAK5205 firmware from a Mac

Issue: Needing to understand how to update the firmware from a Mac?

Setup: macOS 10.15.7

Server: MacBook Pro

Details: It seems that the firmware on my RAK5205 is quite out of date:

========================================================
______  ___   _   __  _    _ _          _               
| ___ \/ _ \ | | / / | |  | (_)        | |              
| |_/ / /_\ \| |/ /  | |  | |_ _ __ ___| | ___  ___ ___ 
|    /|  _  ||    \  | |/\| | | '__/ _ \ |/ _ \/ __/ __|
| |\ \| | | || |\  \ \  /\  / | | |  __/ |  __/\__ \__ \
\_| \_\_| |_/\_| \_/  \/  \/|_|_|  \___|_|\___||___/___/
========================================================
********************************************************
RAK5205 Version:3.0.0.3.H
********************************************************
========================================================

I’m able to issue AT commands via the terminal screen command, but I was hoping that I might upload the latest firmware as per https://downloads.rakwireless.com/LoRa/WisTrio-LoRa-RAK5205/Firmware/. Is this possible?

Thanks,
-C

You can follow the instructions in the RAK5205 Documentation how to update the firmware.

Somehow, I completely missed that. Sorry for the noise.

Actually, I’m receiving “Device firmware upgrade timeout!” issues. Again, I’m able to connect and issue AT commands via:

screen /dev/tty.usbserial-0001 115200

…but cannot via the DFU tool. Any more ideas?

OK, because I had older firmware, I had to go the STM32CubeProgrammer route as documented in your manual.

This appears successful, although I’m unsure whether the device is now booting up correctly. On connecting the serial port, here’s what I’m presented with:

image

However, it will not accept any commands at all… i.e. no input. Please help!

More information having discovered the reset button:

========================================================
______  ___   _   __  _    _ _          _               
| ___ \/ _ \ | | / / | |  | (_)        | |              
| |_/ / /_\ \| |/ /  | |  | |_ _ __ ___| | ___  ___ ___ 
|    /|  _  ||    \  | |/\| | | '__/ _ \ |/ _ \/ __/ __|
| |\ \| | | || |\  \ \  /\  / | | |  __/ |  __/\__ \__ \
\_| \_\_| |_/\_| \_/  \/  \/|_|_|  \___|_|\___||___/___/
========================================================
********************************************************
RAK5205 Version:3.0.0.14.H.R
********************************************************
========================================================
periodic rst is disabled.
UART1 work mode: RUI_UART_NORMAL, 115200, N81
UART3 work mode: RUI_UART_USER, 9600, N81
BME680 init success.
LIS3DH init OK.
GPS Init OK.GPS timeout:100s
autosend_interval: 600s
Current work_mode:LoRaWAN, join_mode:OTAA, MulticastEnable: false, Class: A
Initialization OK 
ERROR: RUI_AT_LORA_PARAMETER_INVALID 82
OK Sleep

My understanding of this latest situation is that the firmware is complaining of there being no LoRaWAN configuration. This doesn’t surprise me given the manual’s recommendation to erase the flash entirely.

Is it possible to flash the configuration via STM32CubeProgrammer?

Hi @huntc ,

Have you set the EUIs and Keys needed to join your LoRaWAN server?

How can I do that? The device isn’t accepting any input over its UART… Please see the screen above. No AT commands are accepted.

I read for other devices that holding down the “1” key puts it into configuration mode. I’m having no such luck here. I suspect the RUI SDK based firmware that I now have behaves differently.

You are using the updated FW so you are good on that aspect.

Hmm…

Did you update the FW in STM32CubeProg via STlink or via USB connection (USB-UART chip)?

Did you perform an erase in the STM32CubeProg when you updated your firmware? That can refresh the flash if something internally messes up.

Also, the RAK5205/RAK7205 will sleep most of the so when you input AT commands, you should expect a wake-up reply first before you can input any AT command.

On each AT command, you should also send a termination \r\n.

Did you update the FW in STM32CubeProg via STlink or via USB connection (USB-UART chip)?

USB-UART

Did you perform an erase in the STM32CubeProg when you updated your firmware? That can refresh the flash if something internally messes up.

Yes.

Also, the RAK5205/RAK7205 will sleep most of the so when you input AT commands, you should expect a wake-up reply first before you can input any AT command.

I see the wake up reply, just nothing output if I attempt to enter any AT command. Prior to the firmware upgrade, I did see output in relation to AT commands being entered (even though my input characters weren’t echoed back).

On each AT command, you should also send a termination \r\n.

I’m presuming that the screen command is doing that. Again, prior to this firmware upgrade, the AT commands were being received and acted on.

Hi @huntc ,

Your FW is functional because of the replies that you got when you restart the device and the wake up when you send a certain command.

When you use STM32CubeProg to update, did you upload the .hex or .bin?

What’s happening now is that your AT commands on the UART RX are not recognized properly.

Few things in my mind:

  1. no proper termination on command.
  2. baud rate is wrong.
  3. FW issues - bug?
  4. HW issue - USB-UART related, jumpers not set properly, etc.

If I am in your situation, I will try again to upload the FW but this time using the RAK DFU Tool. With the updated FW, you must now be able to use the RAK DFU Tool.

Btw, the wake up is triggered just by any rising edge on RX pin.

When you use STM32CubeProg to update, did you upload the .hex or .bin?

Hex - nothing would have worked with the bin!

  1. no proper termination on command.

It wasn’t a problem before. How can I verify?

  1. baud rate is wrong.

Then nothing would be output from the firmware, right?

  1. FW issues - bug?

Can you point me to other versions of the firmware in hex file form? I can then try that.

  1. HW issue - USB-UART related, jumpers not set properly, etc.

Nothing has changed from before.

If I am in your situation, I will try again to upload the FW but this time using the RAK DFU Tool. With the updated FW, you must now be able to use the RAK DFU Tool.

I was able to use the DFU tool. No difference.

Btw, the wake up is triggered just by any rising edge on RX pin.

Thanks. Any further ideas? I appreciate the dialogue.

Hi @huntc ,

You’ve done all the obvious stuff and sadly we can’t still figure it out.

If you have access to an oscilloscope or logic analyzer, I want to give it a try then check the RX pin of the RAK811 itself then decode the signal if something meaningful is really going into it, if the signal is ok and there is still no response the TX pin (by checking the TX pin too and you receive nothing in your PC), it could be a FW bug. But to confirm it, I will try to load again the old FW that you said working before. It is the 3.0.0.12. To do that, you need to upload the bootloader hex (https://downloads.rakwireless.com/LoRa/RAK7205-Tracker/Firmware/RUI_RAK5205_BOOT_Version3_0_2.rar) via STM32CubeProg then upload the FW (https://downloads.rakwireless.com/LoRa/RAK7205-Tracker/Firmware/) via LoRa Button tool - https://downloads.rakwireless.com/LoRa/RAK612-LoRaButton/Tools/RAK%20LoRaButton%20Upgrade%20Tool%20V1.0.zip

Thanks - do you have the hex file just as a zip and not a rar… I can’t decode rar on macOS without installing extra stuff. I appreciate the help, but it baffles me why you’re sending me Windows-based utilities when clearly this issue is about macOS. :stuck_out_tongue:

Hi @huntc ,

This might be a sad news but there is no LoRa button tools SW package for macOS.

It will be really helpful if you can try it to a windows PC. Also, we are not really sure if it is an specific macOS issue.

I’m reasonably confident that this not a macOS issue. I used screen for many types of device and all is well. I’ve now even tried a separate serial port program with no luck. There were no problems programming via AT commands with the older version of the firmware.

Shouldn’t I be able to flash RUI_RAK5205_V3.0.0.12.H.T1_Release.bin directly via STM32CubeProgrammer? This looks to me as though it’ll contain the bootloader given that it is about 128KiB in size… I’m trying this, but without success so far.

For macOS, I am using coolterm. I like it because of the auto-record with .txt output.

Sadly, v3.0.0.12 is only the application code. You need upload first the bootloader hex file then use the LoRa button tool to upload the application fw.

OK, but was does the LoRa button tool actually do? I would think it’d flash the application code to a specific location above the bootloader, no?