Automating RUI v2 Programming

[jackyruth (Jacky Jiang)]

Hello,
We’re trying to automate firmware updating with Ubuntu. We got stuck on the YMODEM protocol.
Here’s the result of our script,

As you can see, we successfully put the RAK module (RAK4270 in this case) in BOOT Mode and started the firmware update process.

We’re using sb command to send a *.bin file to the device through the YMODEM protocol. The Python Code is

import subprocess
import serial
filename = "RAK4270.bin"
ser = serial.Serial("/dev/ttyUSB0",115200,timeout=1)
ser.write(b'at+version\r\n')
print(ser.readline())
ser.write(b'at+boot\r\n')
print(ser.readline())
ser.write(b'at+update\r\n')
print(ser.readline())
ser.close()
subprocess.call(["sudo","bash","ysend", filename])

and the bash script is

#!/bin/sh

DEV=/dev/ttyUSB0

stty -F $DEV 115200
sb $1 > $DEV < $DEV

Does anyone know how to solve the NAK on sector issue?
Thanks

[carlrowan]

Hi Jackyruth,

Are you using the latest FW?
https://downloads.rakwireless.com/LoRa/RAK4270/Firmware/

This should support V3.3.5,Ymode protocol.

[beegee (Bernd Giesecke)]

@jackyruth
I see in your log
RUI Bootloader Version:3.2.6
So your device doesn’t have the default AT command firmware installed.
Here is the log I get when I use default AT command firmware and start the upgrade procedure.

at+version
OK RAK4270 v3.3.0.17
at+boot
<BOOT MODE>
at+update
Start firmware upgrade...
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC

@carlrowan , you have more experience with custom firmware made with RUI. Does it support firmware upgrade over USB with YModem?

[jackyruth (Jacky Jiang)]

Hi,
That is indeed what I get the first time I did it. However, after the YModem transfer failed, only then did it start sending the “AT not supported”.

I am pretty sure the AT command section is fine, because I believe that “Start firmware upgrade…” is a direct response to my “at+upgrade” command

[jackyruth (Jacky Jiang)]

If this is the case, it kind of defeats the purpose of the thing because the purpose is to automate programming.

If there a way to upgrade the firmware to V3.3.5 programmatically?

[carlrowan]

Hi @jackyruth ,

The V3.3.5 is part of the RAK4270 FW versions starting V3.3.0.14. Right now the updated version is V3.3.0.17 which I sent the link on my previous post above. So when you update to the latest FW, the bootloader version should be updated as well. There is no separate bootloader hex starting RAK4270 FW V3.3.0.14.

You can upload the updated FW using STM32CubeProgrammer via UART or ST-LINK. Also use the .hex file and not the .bin file.

[beegee (Bernd Giesecke)]

@jackyruth

“AT not supported”

This is caused because after the failed upload the firmware is still in “Boot” mode and doesn’t accept any AT commands until you reset the node.

I am not familiar with Linux, is there any other command available than sb to send a file with ymodem protocol? Just to see if solves the problem.

[jackyruth (Jacky Jiang)]

Hi all,

@carlrowan Do you think its possible to compile the binary from RUI online compiler, then flash it through SWD w the STM32CubeProgrammer. We can bypass the YModem protocol this way.

I will definitely try this and get back to you.

[carlrowan]

I have to confirm with the SW team but I am afraid that is not possible. When you compiled via RUI, the bootloader will be included already in the .hex file that will be generated. May I know why you want to bypass the YModem protocol?

[jackyruth (Jacky Jiang)]

Just to remove a step from the process. The goal is to automate RAK module programming in the assembly line.

I can successfully upload new firmware using the RAKWireless DFU tool. I am simply attempting to figure out how to automate that process. Could you give more info as to how the DFU tool was implemented? That would be a great help!

(BTW, I updated the firmware with STM32CubeProgrammer as per your suggestion, the issue persists as seen below)