Upgrade to RUI3 on failing on RAK4630

[psupine (Mark Jeffree)]

(System is MacOS)

I was trying to get one of the RUI3 best practice examples going on VSCode/PlatformIO on the RAK4631. Somewhere along the way (I’m not sure how) I bricked the 4631. It wouldn’t show up as a device when connecting to the USB port.

I have a brand new JLink EDU pod ('cause I’m non-commercial) so I thought I should be able to unbrick it. I downloaded the WisCore_RAK4631_Board_Bootloader.hex and tried to use JFlash, but of course that isn’t licensed for the EDU version Jlink. So then I tried to load the same hex file using the Ozone debugger, which I think worked. I had to tell it to just assume that the program entry point would work out ok, and it seemed to be the case.

So now I’m back to an unbricked board with the slow green heartbeat, that identifies as a USB drive when it is plugged in. So far, so good.

Now I’m trying to get RUI3 framework back on to it, working through the “Upgrade to RUI3” tutorial. It fails as shown:

% ./adafruit-nrfutil-macos --verbose dfu serial --package rui3_nrf52840_bootloader_latest.zip -p /dev/cu.usbmodem1101 -b 115200
Traceback (most recent call last):
  File "nordicsemi/__main__.py", line 315, in <module>
  File "click/core.py", line 764, in __call__
  File "click/core.py", line 717, in main
  File "click/core.py", line 1137, in invoke
  File "click/core.py", line 1137, in invoke
  File "click/core.py", line 956, in invoke
  File "click/core.py", line 555, in invoke
  File "nordicsemi/__main__.py", line 288, in serial
  File "nordicsemi/dfu/dfu.py", line 66, in __init__
  File "nordicsemi/dfu/package.py", line 364, in unpack_package
FileNotFoundError: [Errno 2] No such file or directory: '/var/folders/n2/d5q87fd15gq73p4_zmgl8p0h0000gn/T/nrf_dfu_wdic93rc/unpacked_zip/manifest.json'
[5021] Failed to execute script __main__

This is kind of where I was the other day, but was able to avoid it because eventually the WisToolBox managed to do the RUI3 version 4.1.0 update by itself. Today the WisToolBox can’t see the device, I think because it’s presenting as a USB drive.

I see a few possible paths. There might be silly reason I can’t follow the instructions for upgrading to RUI3. Another path would be to install the factory RUI3 hex image directly using Ozone and the Jlink.

I should also be able to just drop some files onto the “USB-4631” drive, but I can’t find a UF2 file to suit.

Thanks in advance.

[beegee (Bernd Giesecke)]

If you open the rui3_nrf52840_bootloader_latest.zip, is the content like this:

Because the uploader is complaining that there is no manifest.json in the file.

[psupine (Mark Jeffree)]

It is exactly as you show there.

[psupine (Mark Jeffree)]

update:

I downloaded bootloader_nrf52840_rak4630.hex from here:

and reflashed the 4631 using Ozone.

Now I can get a response from Arduino’s serial terminal

AT+VER=?

16:27:19.535 -> RUI_BOOT_0.7_nRF52840

[beegee (Bernd Giesecke)]

Not 100% sure, but you might need to flash the s140_nrf52_6.1.0_softdevice.hex as well.
Otherwise you should now be able to flash a RUI3 firmware

[psupine (Mark Jeffree)]

WisToolBox can only talk to the device if I manually identify it, and then RUI3 firmware upgrade fails with this:

{“system”:{“wisToolBoxVersion”:“1.4.4”,“systemVersion”:“macOS 14.5”,“os”:“darwin”},“deviceInfo”:{“connectedAt”:“Tue Jun 04 2024 16:40:44 GMT+1000 (Australian Eastern Standard Time)”,“firmwareVersion”:“rak4630_RUI_4.1.0_RAK4631”,“modelName”:“WisDuo LPWAN Module for LoRaWAN”,“atVersion”:“”,“modelID”:“rak4630”,“serialNumber”:“-”},“dfuInfo”:{“startDFU”:“Tue Jun 04 2024 16:41:38 GMT+1000 (Australian Eastern Standard Time)”,“targetFirmwareVersion”:“rak4630_RUI_4.1.0_RAK4631”,“BaundRate”:“115200”,“endDFU”:“Tue Jun 04 2024 16:41:41 GMT+1000 (Australian Eastern Standard Time)”,“upgradeProcessInfo”:[{“processStatus”:“SWITCH_DFU_MODE”,“timestamp”:“Tue Jun 04 2024 16:41:41 GMT+1000 (Australian Eastern Standard Time)”}],“upgradeStatus”:“FAILED”,“failReason”:“{"code":258,"message":"Error message for known response code from DFU target: Opcode unknown or not supported."}”}}

so it’s not happy.

The only thing that seems odd in this log is “BaundRate”.

Could that be the unknown opcode?

edit: readability

[psupine (Mark Jeffree)]

This morning I decided that yesterday I had already wasted more hours on the problem that the $20 part was worth, so this morning I removed the bricked RAK4631 from the baseboard and replaced it with a brand new one, straight out of the antistatic bag.

I tried to connect it from the Arduino environment. The Arduino environment could not upload anything and reported a series of failed ping timeout messages.

I started the serial monitor and reset the RAK module. The Arduino serial monitor gave me:

10:06:10.568 -> ============================
10:06:10.568 -> LPWAN Tracker Solution
10:06:10.568 -> Built with RAK's WisBlock
10:06:10.568 -> SW Version 1.0.5
10:06:10.568 -> LoRa(R) is a registered trademark or service mark of Semtech Corporation or its affiliates.
10:06:10.568 -> LoRaWAN(R) is a licensed mark.
10:06:10.568 -> ============================
10:06:10.568 -> Device status:
10:06:10.568 ->    RAK4631
10:06:10.568 ->    Auto join disabled
10:06:10.568 ->    Mode LPWAN
10:06:10.568 ->    Network not joined
10:06:10.568 ->    Send Frequency 0
10:06:10.568 -> LPWAN status:

... etc

I tried to force update the firmware using the WisToolBox, but it could not recognise the device automatically, and when I configured the id manually, the firmware update still failed, with the same error log I’ve posted previously, with “baud” spelt “baund”.

I have the sense that the file server end that WisToolBox talks to back at chateau RAK is a bit of a moving target and how well it works changes day to day.

But even putting that aside, I ordered that particular CPU module as part of a WisBlock Starter Kit (19007+4631R) so it seems unusual that it would ship with an application and strange that it seems to be resistant to new uploads.

[beegee (Bernd Giesecke)]

Did you buy a RAK10700 LPWAN Location Tracker?

Because the log output tells me that the firmware on the RAK4631 is for the RAK10700.
And that is not RUI3, it is Arduino based.

Sorry for the inconvenience, did you order a RAK4631 RUI3 version? If yes, the warehouse sent you the wrong version.
Did you buy directly from us or from a local distributor?

[psupine (Mark Jeffree)]

I have only ever bought direct from RAK.

The Packing List # is PACK0008152-1/1, but the trail is a year old so I doubt any fingers can be reliably pointed.

I bought the WisBlock starter (19007 + 4631R/AU915) and some plug in extras.

I should add that the 4631 case has the RUI sticker on it too.

[beegee (Bernd Giesecke)]

Oh, I am so sorry, that is a major mistake in our logistics.

You will have to go through the process of flashing RUI3 on the device.

You said you can flash through Ozone and a JLink adapter, that will be the best solution, because WisToolBox is not able to flash the bootloader and softdevice.

Take the RUI3 .hex file for the RAK4631 from our download center and flash it, it contains everything you need.

[psupine (Mark Jeffree)]

I can reflash through Ozone and Jlink, but not up to a working system. I can get it to respond to AT+VER=?, but that’s all I get. No downloads from Arduino and no recognition from WisToolBox.

As you suggested I reflashed the S140*.hex too, but that didn’t get all the way to a working system. I either need to be able to finish up with WisToolBox or with another *.hex file, because the one I pulled from GitHub yesterday only got me half way there.

I can have another try, but you’ll have to point me to the right files. Is it

/RUI3/Image/RAK4631_latest_final.hex ?

[beegee (Bernd Giesecke)]

I will make a flash dump of a working RAK4631 RUI3 and send to you. That will include everything.
When switching between RUI3 and Arduino I am always using these flash dump files.

RAK4631-RUI3-V4.1.1-Flash-Dump.hex (2.4 MB)

[psupine (Mark Jeffree)]

That has rescued yesterday’s board.

I’ll have to solder the pin header onto today’s board and go again, but I expect it will work too. Thanks for your help.

[psupine (Mark Jeffree)]

Before we close this thread out, I need to make sure I have the LoRa settings appropriate to AU915. Is the localisation script of AT commands available for this?

[beegee (Bernd Giesecke)]

Yes, use AT+BAND=6 for AU915 and AT+MASK=000x. (x) depends on which subbands you have setup in the gateway and LNS.

[psupine (Mark Jeffree)]

I was looking at this before you answered, and now I’m * more * confused ?!

from WisBlock-API/AT-Commands.md at main · beegee-tokyo/WisBlock-API · GitHub

[beegee (Bernd Giesecke)]

WisBlock-API is outdated. WisBlock-API-V2 is using same as RUI3. But anyway you are now on RUI3.
RUI3 has different definition T+BAND

[psupine (Mark Jeffree)]

Thanks for clarifying.