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
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.
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?
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.
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.
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.
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.
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.
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”?
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.
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.
Hello,
I have the same problem. I have just purchased a new rak4630. I can’t access it via USB.
Even I can’t upgrade the bootloader over [BLE OTA DFU ] because one the steps to follow needs the usb connection : "RAK4631 flashed with a firmware that supports OTA DFU, e.g. [ble_ota_dfu] .
I have this same problem cant access com port to update the boot loader. When pluged in it starts as a drive with access to bootloader version. I have tried arduino ide no com port and the windows command prompt boot loader update bit fails wvery time.
Do you have any other modules plugged into the WisBlock Base Board?
When showing as USB drive, there should be still a COM port showing.
Did you try different USB ports and different USB cables?
Yes i pluged in everthing that came with the gps tracker kit havnt tried just the wiscore . Have tried different working USB cables. Different USB ports.
The ports are a bit strange as i use to get a new port swaping an arduino board between usb ports but now i dont. Its always com 9. So i checked hidden com ports in device manager and found most of them inuse but not visable. Deleted all except comport 9. Now most are free again . It is possible something is reserving them all.
Under device managment the wisblock is under >other devices -Wiscore rak4631 board
Or
Other devices - nRF Serial (if double click reset on start up).
Windows 7. It would show as nrf device (i think) and wisblock depending on the mode it was in. Tried auto updating drivers and it didnt work. I found a post where you recommend updating the drivers with adafruit driver package.