Unable to update bootloader on 4630

lysander · October 8, 2021, 10:13pm

I have been hacking away on this for 2 days now without any luck. The issue started with a sudden loss of the ability to compile/upload a sketch that had been loading intermittently (2/3 of the time?). Now the upload breaks at

I have tried unsuccessfully to update the bootloader on both 4630s on both Linux and Windows. On Windows I get:

On linux it gets a few steps beyond “Touched serial port /dev/ttyACM0” but hangs at “Sending DFU start packet”

I have researched extensively and been unable to find anything that helps. Any feedback would be greatly appreciated.

beegee · October 9, 2021, 5:50am

Hello @lysander
Did you upgrade your bootloader? => Bootlaoder update

When you push the reset button twice quickly, does the RAK4631 show up as an UF2 drive in Windows?

This part of the error message points towards a problem with the COM port being occupied:

I made the bad experience that Ultimaker Cura (3D printing software) is occupying all COM ports it finds (hoping a 3D printer is attached somewhere) while it is running. Make sure nothing else that uses COM ports is running.

lysander · October 9, 2021, 6:15pm

Thanks for the speedy reply, @beegee .

I can not update the bootloader per Updated bootloader for RAK4631, though. The first option to use BLE requires that a BLE scketch be installed which requires the updated bootloader. The second option appears to require a JLink device and/or (per WisBlock/bootloader/RAK4630 at master · RAKWireless/WisBlock · GitHub) wiring the 4630 to another device (it is unclear in the image as to what the SWD pins are supposed to connect to). Apologies but I am a total noob with Arduino (if that’s not totally obvious!)

As for the com port being busy/in use by another device, I have confirmed that it only activates (ie, appears on Device Manager) when I plug in the USB cable from the 4630. Any idea as to how to confirm that nothing else is using COM ports?

Editing: does this PR have anything to do with the problem I’m encountering?

k3nt · October 9, 2021, 7:00pm

I think what you may be experiencing is the changing of serial ports from the initial touch operation to the reset into the bootloader. When the bootloader flashing utility initiates, it first uses a simple trick to reset the device by opening and closing the serial port at baud 1200, it then waits for the device to come back, but expects it be on the same exact serial port. More commonly on Windows, the COM port will increment by one after the device resets and therefore attempts communicating with the bootloader on the wrong COM port. I would suggest watching the COM port in Window’s device manager when attempting the upload to see if the COM# is changing.

beegee · October 10, 2021, 9:22am

@lysander
Did you try to double push the reset button to put the RAK4631 into UF2 bootloader mode?
It should appear as a drive:

Then you can compile and upload the ble_ota_dfu.ino sketch. Just select the correct COM port:

You can use the same method to update your bootloader.

Force RAK4631 into UF2 bootloader mode and select the new COM port you find for RAK4631
Select Programmer: "Bootloader DFU for Bluefruit nRF52" in the &&Tools** menu
Click on Burn Bootloader

image917×476 20.7 KB

@k3nt , welcome to the forum.
You are right, the COM port changes during the upload process, but the uploader is aware of it and handles it.

lysander · October 10, 2021, 6:57pm

Thanks, @beeegee and @k3nt.

As indicated at the beginning of this thread, I am trying to get this to work on either Linux or Windows (ideally both but I’ll at least be able to proceed for now with whichever works). I will try the Windows fix later. For now, though, I am on Linux and, after successfully installing ble_ota_dfu.ino (progress!), I get the following when attempting to burn the updated bootloader:


Usage: adafruit-nrfutil dfu serial [OPTIONS]
Try "adafruit-nrfutil dfu serial --help" for help.

Error: Invalid value for "-pkg" / "--package": File "/home/jg/.arduino15/packages/rakwireless/hardware/nrf52/0.21.20/bootloader/WisCore_RAK4631_Board/WisCore_RAK4631_Board_bootloader-0.3.2_s140_6.1.1.zip" does not exist.
Error while burning bootloader.


This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

This error seems to indicate that the path to the package with the correct bootloader is wrong.

Attempting to further troubleshoot, from WisBlock/bootloader/RAK4630/new/Adafruit_nRF52_Bootloader_new at master · RAKWireless/WisBlock · GitHub, running git submodule update --init appeared to run successully. Still no luck burning the bootloader.

Presumably there is a path setting somewhere that needs to be changed although I am not sure if that is something I can do or if it is in the “burn” code.

Note that I have not updated the BSP per GitHub - RAKWireless/RAKwireless-Arduino-BSP-Index: RAKwireless BSP Support for the Arduino Board Manager. I am hesitant to do so unless/until I get this bootloader issue resolved.

Please advise.

k3nt · October 10, 2021, 6:19pm

Apologies, I should’ve specified the tool and environment I was referring to. Adafruit-nrfutil itself does not auto detect any changes in port from touch to dfu upload, this can be seen here and here. This is also evident in the Windows terminal screenshot from @lysander. When uploading in PlatformIO or Arduino, the touch operation is done separately by the upload system and then Adafruit-nrfutil is then used only to do the dfu upload.

lysander · October 10, 2021, 7:30pm

Unsuccessful on my Windows machine:

As can be seen in the screenshot, the DFU happens on COM7 (see first message in red in the Arduinio IDE terminal output) whereas the 4630 is connected to COM5 (see both the “Tools” menu selection as well as the status bar at the bottom right). Also, the “Upgrading target on…” error pops every time I try to install the LoRaWAN sketch even though the new bootloader is present. So, I presume the problem with the COM port changing the @k3nt mentioned above is the source of the problem on Windows.

@beegee - please let me know if I should start a separate thread for this Windows/COM port assignment issue for future resolution seekers.

k3nt · October 10, 2021, 7:48pm

@lysander So that looks like a successful DFU upload from your screenshot, what makes you think it wasn’t.

lysander · October 10, 2021, 8:23pm

I might just be getting confused by the terminal messages, @k3nt. As I attempted to detail above, the discrepancies with the COM ports seem to imply that the custom LoRa sketch in the path is getting uploaded onto COM7. However, the 4630 is on COM5. So, it is unclear as to whether the sketch is actually making it to the right port and onto the 4630.

Presuming the “Device programmed” message is correct and indeed confirms that the LoRa script made it to the 4630, I can not see evidence anywhere that the script is actually firing.

Stepping back a bit, I’d been compiling/uploading/running this same script on an Ubuntu machine without issue before it just stopped working leading to the creation of this support ticket. Join requests/accepts were being received in Helium Console successfully (and DCs getting charged) before so I know the credentials are correct. I do not see any such confirmation of reception now on Console from the same device, though, after this attempt to install the sketch.

Do you know if there is a serial output from the 4630 to confirm that it is firing? Or do you have any other guidance as to know the state of the 4630 after receiving “Device programmed”?

k3nt · October 10, 2021, 8:37pm

If you see the success message, then it did in fact succeed, there are several back and forth transactions between the host and device during the upload process to confirm this. I have likely created unnecessary confusion with the COM port discussion so my apologies. If you are using Arduino or PlatformIO to upload, there are more things happening in the background to find and use the correct port then there are when you use the Adafruit-nrfutil utility alone. You should see serial output from the sketch, it can be easy to miss the initial serial output sometimes though because you must wait for the port to enumerate and connect to before seeing them.

lysander · October 10, 2021, 8:56pm

You are correct, @k3nt. It was firing after the “Device programmed” messages after all. I’d confused myself about the output from the build forgetting that the output I was looking for regarding the LoRa traffic was on the Arduino IDE serial monitor. Did I mention I’m a noob with Arduino?!

So, I think I am good with the bootloader/firmware updates. Now I will try to understand the Wisblock/4630 example and why the packets from it are being received on Helium Console with empty payloads.

Thanks for the assist.