After I updated the bootloader, how can I verify that I am running the new version?
Connect the RAK4631 over USB to your PC.
Double click RESET to get into bootloader/UF2 mode
On your PC open the new drive that is mounted:
Open the INFO_UF2.TXT text file. The bootloader compilation date will be shown:
Hi Bernd
I received my Wisblock 4630/1901 SHTC3 Temp/Humidity sensor yesterday and I’m having quite a few issues with it.
Uploading to the device works very occasionally - around 1 in 6-10 times (from 2 different Windows 10 laptops).
I have tried upgrading the bootloader via BLE (as I don’t have a J-Link). It eventually flashed and ran - the blue and green LED flashed, then just the blue. I connected over BLE with my phone and the blue LED stopped flashing. I then sent the DFU zip file as per the instruction and it got to 0% and then reported that it had disconnected. I tried this a few time and got the same error.
Also, I am trying to merge the 4630 comms example code with 1901 example code so that I can read the sensor every 20 seconds and send the data over LoRa. I have seen the sensor read and the lora join/transmit all working fine but it often crashes and I’m not sure if it’s to do with the hardware or my firmware. Do you have a complete working example of a 4630 with 1901 that does something similar to what I am trying to do?
And finally, SHTC3 library (http://librarymanager/All#SparkFun_SHTC3) has versions 1.1.3, 1.1.2, 1.1.1, 1.0.3 and 1.02. I tried 1.1.3 and that didn’t work at all. 1.1.2 seems to work (other than it may be the cause of the crashes). How do I know which to select?
My setup is below, as are some of the upload failure logs. Any help would be appreciated!
------------
Sketch uses 106224 bytes (13%) of program storage space. Maximum is 815104 bytes.
Global variables use 13132 bytes (5%) of dynamic memory, leaving 224436 bytes for local variables. Maximum is 237568 bytes.
processing.app.debug.RunnerException
at cc.arduino.packages.uploaders.SerialUploader.uploadUsingPreferences(SerialUploader.java:152)
at cc.arduino.UploaderUtils.upload(UploaderUtils.java:77)
at processing.app.SketchController.upload(SketchController.java:732)
at processing.app.SketchController.exportApplet(SketchController.java:703)
at processing.app.Editor$UploadHandler.run(Editor.java:2055)
at java.lang.Thread.run(Thread.java:748)
Caused by: processing.app.SerialException: Error touching serial port 'COM4'.
at processing.app.Serial.touchForCDCReset(Serial.java:107)
at cc.arduino.packages.uploaders.SerialUploader.uploadUsingPreferences(SerialUploader.java:136)
... 5 more
Caused by: jssc.SerialPortException: Port name - COM4; Method name - openPort(); Exception type - Port not found.
at jssc.SerialPort.openPort(SerialPort.java:167)
at processing.app.Serial.touchForCDCReset(Serial.java:101)
... 6 more
processing.app.SerialException: Error opening serial port 'COM4'.
at processing.app.Serial.<init>(Serial.java:152)
at processing.app.Serial.<init>(Serial.java:82)
at processing.app.SerialMonitor$2.<init>(SerialMonitor.java:132)
at processing.app.SerialMonitor.open(SerialMonitor.java:132)
at processing.app.AbstractMonitor.resume(AbstractMonitor.java:132)
at processing.app.Editor.resumeOrCloseSerialMonitor(Editor.java:2120)
at processing.app.Editor.access$1300(Editor.java:117)
at processing.app.Editor$UploadHandler.run(Editor.java:2089)
at java.lang.Thread.run(Thread.java:748)
Caused by: jssc.SerialPortException: Port name - COM4; Method name - openPort(); Exception type - Port not found.
at jssc.SerialPort.openPort(SerialPort.java:167)
at processing.app.Serial.<init>(Serial.java:141)
... 8 more
Error opening serial port 'COM4'.
--------------------------
Sketch uses 106224 bytes (13%) of program storage space. Maximum is 815104 bytes.
Global variables use 13132 bytes (5%) of dynamic memory, leaving 224436 bytes for local variables. Maximum is 237568 bytes.
Upgrading target on COM5 with DFU package C:\Users\RICHAR~1\AppData\Local\Temp\arduino_build_924119\LoRaWAN_OTAA_rs-wisblock-1.1.ino.zip. Flow control is disabled, Single bank, Touch disabled
########################################
########################################
#######################################Timed out waiting for acknowledgement from device.
Failed to upgrade target. Error is: No data received on serial port. Not able to proceed.
Traceback (most recent call last):
File "nordicsemi\__main__.py", line 294, in serial
File "nordicsemi\dfu\dfu.py", line 235, in dfu_send_images
File "nordicsemi\dfu\dfu.py", line 206, in _dfu_send_image
File "nordicsemi\dfu\dfu_transport_serial.py", line 213, in send_firmware
File "nordicsemi\dfu\dfu_transport_serial.py", line 243, in send_packet
File "nordicsemi\dfu\dfu_transport_serial.py", line 282, in get_ack_nr
nordicsemi.exceptions.NordicSemiException: No data received on serial port. Not able to proceed.
Possible causes:
- Selected Bootloader version does not match the one on Bluefruit device.
Please upgrade the Bootloader or select correct version in Tools->Bootloader.
- Baud rate must be 115200, Flow control must be off.
- Target is not in DFU mode. Ground DFU pin and RESET and release both to enter DFU mode.
---------
Sketch uses 105960 bytes (12%) of program storage space. Maximum is 815104 bytes.
Global variables use 14872 bytes (6%) of dynamic memory, leaving 222696 bytes for local variables. Maximum is 237568 bytes.
Upgrading target on COM5 with DFU package C:\Users\RICHAR~1\AppData\Local\Temp\arduino_build_313449\ble_ota_dfu.ino.zip. Flow control is disabled, Single bank, Touch disabled
########################################
########################################
########################################
########################################
########################################
#######
Activating new firmware
Device programmed.
Thanks
Richard.
@richstimson
Hello and first of all, sorry for slightly editing your post, but it was very difficult to read without some formatting.
a) About the USB upload problem. Did you try a different USB cable as well?
b) Updating the bootloader over BLE. Without JLink, BLE is the only option to update the bootloader. The error that you report ... it got to 0% and then reported that it had disconnected. is strange. Do you have the option to try from a different Android phone to do the upload? Which Android app did you try? Nordic nRF Connect or My nRF52 Toolbox or both?
c) SHTC3 library version. I have a WisBlock running here that uses the RAK1901 and I am using the Sparkfun SHTC3 library version 1.1.3 and it compiles and works without problems. What exactly is not working for you with this library?
d) Example with RAK1901 and LoRaWAN.
We have the Weather_monitoring example that uses the RAK1901, RAK1902 and RAK1903 sensors and send the data over LoRaWAN. You can use this as a base, just remove the functions that collects data from the RAK1902 and RAK1903.
Hi Bernd
(a)
I tried a different USB cable and get the same issues - the COM port changes everytime (which I think is just a Windows USB thing). These are a couple more of the logs:
===================
Upgrading target on COM4 with DFU package C:\Users\RICHAR~1\AppData\Local\Temp\arduino_build_983227\ble_ota_dfu.ino.zip. Flow control is disabled, Single bank, Touch disabled
########################################
########################################
########################################
########################################
########################################
#Timed out waiting for acknowledgement from device.
Failed to upgrade target. Error is: No data received on serial port. Not able to proceed.
Traceback (most recent call last):
File “nordicsemi_main_.py”, line 294, in serial
File “nordicsemi\dfu\dfu.py”, line 235, in dfu_send_images
File “nordicsemi\dfu\dfu.py”, line 206, in _dfu_send_image
File “nordicsemi\dfu\dfu_transport_serial.py”, line 213, in send_firmware
File “nordicsemi\dfu\dfu_transport_serial.py”, line 243, in send_packet
File “nordicsemi\dfu\dfu_transport_serial.py”, line 282, in get_ack_nr
nordicsemi.exceptions.NordicSemiException: No data received on serial port. Not able to proceed.
Possible causes:
- Selected Bootloader version does not match the one on Bluefruit device.
Please upgrade the Bootloader or select correct version in Tools->Bootloader. - Baud rate must be 115200, Flow control must be off.
- Target is not in DFU mode. Ground DFU pin and RESET and release both to enter DFU mode.
==================
Below shows failure halfway through ble_ota_dfu upload:
================
Sketch uses 105976 bytes (13%) of program storage space. Maximum is 815104 bytes.
Global variables use 14872 bytes (6%) of dynamic memory, leaving 222696 bytes for local variables. Maximum is 237568 bytes.
Upgrading target on COM5 with DFU package C:\Users\RICHAR~1\AppData\Local\Temp\arduino_build_983227\ble_ota_dfu.ino.zip. Flow control is disabled, Single bank, Touch disabled
########################################
########################################
########################################
################################Timed out waiting for acknowledgement from device.
Failed to upgrade target. Error is: No data received on serial port. Not able to proceed.
Traceback (most recent call last):
File “nordicsemi_main_.py”, line 294, in serial
File “nordicsemi\dfu\dfu.py”, line 235, in dfu_send_images
File “nordicsemi\dfu\dfu.py”, line 206, in _dfu_send_image
File “nordicsemi\dfu\dfu_transport_serial.py”, line 213, in send_firmware
File “nordicsemi\dfu\dfu_transport_serial.py”, line 243, in send_packet
File “nordicsemi\dfu\dfu_transport_serial.py”, line 282, in get_ack_nr
nordicsemi.exceptions.NordicSemiException: No data received on serial port. Not able to proceed.
Possible causes:
- Selected Bootloader version does not match the one on Bluefruit device.
Please upgrade the Bootloader or select correct version in Tools->Bootloader. - Baud rate must be 115200, Flow control must be off.
- Target is not in DFU mode. Ground DFU pin and RESET and release both to enter DFU mode.
=================
( c ) & (d) I have upgraded to SHTC 1.1.3 and tried the weather station (with the pressure/light sensors commented out). It works a lot better so I will investigate what the problem was with my version.
I’m still getting LORAMAC_STATUS_BUSY on my connection to TTN and I’m not sure why that is. I get a success every 3 sends (once per minute) - this is consistent.
15:38:44.730 → =====================================
15:38:44.730 → Welcome to RAK4630 LoRaWan!!!
15:38:44.730 → Type: OTAA
15:38:44.730 → Region: EU868
15:38:44.730 → =====================================
15:38:44.730 → shtc3 init
15:38:44.730 → Beginning sensor. Result =
15:38:44.730 → ID Passed Checksum. Device ID: 0b100001000111
15:38:44.730 → [OTAA ]
15:38:44.730 → DevEui=AC-1F-09-FF-FE-03-EF-DF
15:38:44.730 → DevAdd=00000000
15:38:44.730 → AppEui=70-B3-D5-7E-D0-04-08-BB
15:38:44.730 → AppKey=A9-03-A3-5F-DB-5C-FA-18-AB-92-7F-4F-0E-58-56-73
15:38:44.811 → [LMH ] Selected subband 1
15:38:44.811 →
15:38:44.811 → BSP Library : 0.21.001
15:38:44.811 → Bootloader : s140 6.1.1
15:38:44.811 → Serial No : 569705986BC2F74B
15:38:44.811 →
15:38:44.879 → [LM ] OnRadioTxDone
15:38:44.879 → [LM ] OnRadioTxDone => RX Windows #1 4989 #2 5995
15:38:44.879 → [LM ] OnRadioTxDone => TX was Join Request
15:38:49.957 → [LM ] OnRadioRxDone
15:38:49.957 → [LM ] OnRadioRxDone => FRAME_TYPE_JOIN_ACCEPT
15:38:49.957 → OTAA Mode, Network Joined!
15:39:10.979 → Sending frame now…
15:39:10.979 → result: Tem:24.18C Hum:32.92%
15:39:10.979 → lmh_send ok count 1
15:39:12.284 → [LM ] OnRadioTxDone
15:39:12.284 → [LM ] OnRadioTxDone => RX Windows #1 1030 #2 1995
15:39:17.325 → [RADIO ] RadioIrqProcess => IRQ_RX_TX_TIMEOUT
15:39:17.325 → [LM ] OnRadioRxTimeout
15:39:19.308 → [LM ] OnRadioTxDone
15:39:19.308 → [LM ] OnRadioTxDone => RX Windows #1 1030 #2 1995
15:39:24.321 → [RADIO ] RadioIrqProcess => IRQ_RX_TX_TIMEOUT
15:39:24.321 → [LM ] OnRadioRxTimeout
15:39:26.331 → [LM ] OnRadioTxDone
15:39:26.331 → [LM ] OnRadioTxDone => RX Windows #1 1030 #2 1995
15:39:30.975 → Sending frame now…
15:39:30.975 → result: Tem:24.16C Hum:33.26%
15:39:30.975 → [LM ] LoRaMacMcpsRequest LORAMAC_STATUS_BUSY
15:39:30.975 → [LMH ] lmh_send → LoRaMacMcpsRequest failed
15:39:30.975 → lmh_send fail count 1
15:39:31.350 → [RADIO ] RadioIrqProcess => IRQ_RX_TX_TIMEOUT
15:39:31.350 → [LM ] OnRadioRxTimeout
15:39:33.349 → [LM ] OnRadioTxDone
15:39:33.349 → [LM ] OnRadioTxDone => RX Windows #1 1030 #2 1995
15:39:38.353 → [RADIO ] RadioIrqProcess => IRQ_RX_TX_TIMEOUT
15:39:38.353 → [LM ] OnRadioRxTimeout
15:39:40.358 → [LM ] OnRadioTxDone
15:39:40.358 → [LM ] OnRadioTxDone => RX Windows #1 1030 #2 1995
15:39:45.379 → [RADIO ] RadioIrqProcess => IRQ_RX_TX_TIMEOUT
15:39:45.379 → [LM ] OnRadioRxTimeout
15:39:47.370 → [LM ] OnRadioTxDone
15:39:47.370 → [LM ] OnRadioTxDone => RX Windows #1 1030 #2 1995
15:39:50.955 → Sending frame now…
15:39:50.955 → result: Tem:24.18C Hum:33.46%
15:39:50.955 → [LM ] LoRaMacMcpsRequest LORAMAC_STATUS_BUSY
15:39:50.955 → [LMH ] lmh_send → LoRaMacMcpsRequest failed
15:39:50.955 → lmh_send fail count 2
15:39:52.397 → [RADIO ] RadioIrqProcess => IRQ_RX_TX_TIMEOUT
15:39:52.397 → [LM ] OnRadioRxTimeout
15:39:54.359 → [LM ] OnRadioTxDone
15:39:54.397 → [LM ] OnRadioTxDone => RX Windows #1 1030 #2 1995
15:39:59.397 → [RADIO ] RadioIrqProcess => IRQ_RX_TX_TIMEOUT
15:39:59.397 → [LM ] OnRadioRxTimeout
15:40:01.408 → [LM ] OnRadioTxDone
15:40:01.408 → [LM ] OnRadioTxDone => RX Windows #1 1030 #2 1995
15:40:06.419 → [RADIO ] RadioIrqProcess => IRQ_RX_TX_TIMEOUT
15:40:06.419 → [LM ] OnRadioRxTimeout
15:40:10.948 → Sending frame now…
15:40:10.948 → result: Tem:24.31C Hum:33.68%
15:40:10.983 → lmh_send ok count 2
15:40:12.318 → [LM ] OnRadioTxDone
15:40:12.318 → [LM ] OnRadioTxDone => RX Windows #1 1030 #2 1995
I hoping that formatting is ok this time - it looks ok right now.
Thanks again for your support.
Richard.
Hi @richstimson ,
Can you create a new and separate forum topic for this issue? I work mainly on EU868 so I will try to replicate your issue. If possible, please just send me the sketch or post it on your new forum post. Bernd mainly use US915 and AS923 so I might be the better person to assist you. Please tag me when you create your forum topic. Thanks 
Cheers,
Carl
@richstimson
Can you check your code if there are two independent running functions that are calling lmh_send()?
Because when I check your log, there is one function calling lmh_send(), which announces its sending with Sending frame now. See the green boxes in the image.
But there is a second call to lmh_send() which runs with a much higher frequency and it interferes with the other sending calls. See the red boxes in the image.
Everytime the green box tries to send while the red box is still sending, the transmission fails (logically).
The weather station example code starts a counter that automatically sends a LoRaWAN packet every LORAWAN_APP_INTERVAL seconds.
If you try to send manually from the loop() (I guess) as well, the two send commands are colliding and that leads to the failed transmissions.
Hi @beegee , @carlrowan,
Thanks for your replies. I will look in to this more and raise a new topic if I don’t find the issue (or update you here if I do).
Kind regards
Richard.
Please open a new topic.
This topic was raised for the Bootloader Update, not for your application issue.
Hi,
Was this bootloader issue resolved?
I have two RAK5005+RAK4630 with the same issue.
Original problem is that with the GPS-module attached to the 5005 board, it will not start executing the sketch after power-on until you press the reset-button. I have seen others suggesting that upgrading the 4630 bootloader may fix this.
On arrival, the device was according to its INFO_UF2.TXT file installed with:
UF2 Bootloader 0.3.2-109-gd6b28e6-dirty lib/nrfx (v2.0.0) lib/tinyusb (0.6.0-272-g4e6aa0d8) lib/uf2 (heads/master)
Model: Adafruit Feather nRF52840 Express
Board-ID: nRF52840-Feather-revD
SoftDevice: S140 version 6.1.1
Date: Jun 16 2020
Loading the ble_ota_dfu sketch, bluetooth lights up and I can connect to it from an Android device with nRF Connect. I open DFU and select RAK4630_bootloader-0.4.1.zip.
Exactly as described in the previous post in this thread, it gets to 0% upload, then the 4630 disconnects.
nRF Connect receives Op Code = 3, Status = 6, which accoring to some searches on Nordic Semisonductor’s forum seems to indicate an incompatible zip package?
I tried with different Android devices and two different RAK4630.
Complete nRF Connect log:
nRF Connect, 2021-05-02
RAK4631_OTA (E9:77:F4:87:BF:C6)
V 12:23:27.606 Connecting to E9:77:F4:87:BF:C6...
D 12:23:27.606 gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
D 12:23:27.751 [Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
I 12:23:27.751 Connected to E9:77:F4:87:BF:C6
D 12:23:27.753 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
V 12:23:27.805 Discovering services...
D 12:23:27.805 gatt.discoverServices()
I 12:23:28.559 PHY updated (TX: LE 2M, RX: LE 2M)
I 12:23:29.009 Connection parameters updated (interval: 30.0ms, latency: 0, timeout: 2000ms)
D 12:23:29.371 [Callback] Services discovered with status: 0
I 12:23:29.372 Services discovered
V 12:23:29.401 Generic Access (0x1800)
- Device Name [R W] (0x2A00)
- Appearance [R] (0x2A01)
- Peripheral Preferred Connection Parameters [R] (0x2A04)
- Central Address Resolution [R] (0x2AA6)
Generic Attribute (0x1801)
- Service Changed [I] (0x2A05)
Client Characteristic Configuration (0x2902)
Device Firmware Update Service (00001530-1212-efde-1523-785feabcd123)
- DFU Packet [WNR] (00001532-1212-efde-1523-785feabcd123)
- DFU Control Point [N W] (00001531-1212-efde-1523-785feabcd123)
Client Characteristic Configuration (0x2902)
- DFU Version [R] (00001534-1212-efde-1523-785feabcd123)
D 12:23:29.401 gatt.setCharacteristicNotification(00002a05-0000-1000-8000-00805f9b34fb, true)
I 12:23:29.425 Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)
I 12:23:29.456 Connection parameters updated (interval: 30.0ms, latency: 0, timeout: 2000ms)
V 12:23:41.811 [DFU] DFU service started
V 12:23:41.811 [DFU] Opening file...
I 12:23:41.852 [DFU] Firmware file opened successfully
V 12:23:41.852 [DFU] Connecting to DFU target...
D 12:23:41.853 [DFU] gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferredPhy = LE_1M | LE_2M)
I 12:23:41.865 [DFU] Connected to E9:77:F4:87:BF:C6
V 12:23:41.866 [DFU] Discovering services...
D 12:23:41.866 [DFU] gatt.discoverServices()
I 12:23:41.868 [DFU] Services discovered
D 12:23:41.887 [DFU] wait(1000)
V 12:23:42.924 [DFU] Reading DFU version number...
D 12:23:42.924 [DFU] gatt.readCharacteristic(00001534-1212-efde-1523-785feabcd123)
I 12:23:42.987 [DFU] Read Response received from 00001534-1212-efde-1523-785feabcd123, value (0x): 01-00
A 12:23:42.987 [DFU] Version number read: 0.1
W 12:23:42.992 [DFU] Application with buttonless update found
V 12:23:42.993 [DFU] Jumping to the DFU Bootloader...
V 12:23:42.993 [DFU] Enabling notifications for 00001531-1212-efde-1523-785feabcd123
D 12:23:42.993 [DFU] gatt.setCharacteristicNotification(00001531-1212-efde-1523-785feabcd123, true)
D 12:23:42.996 [DFU] gatt.writeDescriptor(00002902-0000-1000-8000-00805f9b34fb, value=0x01-00)
I 12:23:43.049 [DFU] Data written to descr.00001531-1212-efde-1523-785feabcd123, value (0x): 01-00
V 12:23:43.051 [DFU] Notifications enabled for 00001531-1212-efde-1523-785feabcd123
A 12:23:43.051 [DFU] Notifications enabled
D 12:23:43.051 [DFU] wait(1000)
V 12:23:44.070 [DFU] Writing to characteristic 00001531-1212-efde-1523-785feabcd123
D 12:23:44.071 [DFU] gatt.writeCharacteristic(00001531-1212-efde-1523-785feabcd123)
D 12:23:46.104 [Callback] Connection state changed with status: 8 and new state: DISCONNECTED (0)
E 12:23:46.104 Error 8 (0x8): GATT CONN TIMEOUT
I 12:23:46.104 Disconnected
A 12:23:46.150 [DFU] Jump to bootloader sent (Op Code = 1, Upload Mode = 4)
I 12:23:46.150 [DFU] Disconnected by the remote device
D 12:23:46.150 [DFU] gatt.refresh() (hidden)
D 12:23:46.150 [DFU] gatt.disconnect()
D 12:23:46.151 [DFU] gatt.close()
D 12:23:46.151 [Broadcast] Action received: android.bluetooth.device.action.ACL_DISCONNECTED
D 12:23:46.171 [DFU] [Broadcast] Action received: android.bluetooth.device.action.ACL_DISCONNECTED
V 12:23:46.192 [DFU] DFU service started
I 12:23:46.192 [DFU] Firmware file opened successfully
D 12:23:46.192 [DFU] wait(1000)
D 12:23:47.193 [DFU] wait(1000)
V 12:23:48.223 [DFU] Connecting to DFU target...
D 12:23:48.262 [DFU] gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferredPhy = LE_1M | LE_2M)
I 12:23:49.353 [DFU] Connected to E9:77:F4:87:BF:C6
D 12:23:49.353 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
D 12:23:49.405 [DFU] [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
V 12:23:49.405 [DFU] Discovering services...
D 12:23:49.405 [DFU] gatt.discoverServices()
I 12:23:50.054 [DFU] Services discovered
D 12:23:50.082 [DFU] wait(1000)
V 12:23:51.071 [DFU] Reading DFU version number...
D 12:23:51.072 [DFU] gatt.readCharacteristic(00001534-1212-efde-1523-785feabcd123)
I 12:23:51.237 [DFU] Read Response received from 00001534-1212-efde-1523-785feabcd123, value (0x): 08-00
A 12:23:51.239 [DFU] Version number read: 0.8
D 12:23:51.243 [DFU] wait(1000)
V 12:23:52.244 [DFU] Enabling notifications for 00001531-1212-efde-1523-785feabcd123
D 12:23:52.245 [DFU] gatt.setCharacteristicNotification(00001531-1212-efde-1523-785feabcd123, true)
D 12:23:52.246 [DFU] gatt.writeDescriptor(00002902-0000-1000-8000-00805f9b34fb, value=0x01-00)
I 12:23:52.316 [DFU] Data written to descr.00001531-1212-efde-1523-785feabcd123, value (0x): 01-00
V 12:23:52.318 [DFU] Notifications enabled for 00001531-1212-efde-1523-785feabcd123
A 12:23:52.318 [DFU] Notifications enabled
D 12:23:52.318 [DFU] wait(1000)
V 12:23:53.319 [DFU] Writing to characteristic 00001531-1212-efde-1523-785feabcd123
D 12:23:53.320 [DFU] gatt.writeCharacteristic(00001531-1212-efde-1523-785feabcd123)
I 12:23:53.397 [DFU] Data written to 00001531-1212-efde-1523-785feabcd123, value (0x): 01-03
A 12:23:53.397 [DFU] DFU Start sent (Op Code = 1, Upload Mode = 3)
V 12:23:53.397 [DFU] Writing to characteristic 00001532-1212-efde-1523-785feabcd123
D 12:23:53.397 [DFU] gatt.writeCharacteristic(00001532-1212-efde-1523-785feabcd123)
I 12:23:53.405 [DFU] Data written to 00001532-1212-efde-1523-785feabcd123, value (0x): E8-4D-02-00-58-98-00-00-00-00-00-00
A 12:23:53.405 [DFU] Firmware image size sent (151016b, 39000b, 0b)
I 12:24:01.955 [DFU] Notification received from 00001531-1212-efde-1523-785feabcd123, value (0x): 10-01-01
A 12:24:01.955 [DFU] Response received (Op Code = 1 Status = 1)
A 12:24:01.955 [DFU] Writing Initialize DFU Parameters...
V 12:24:01.955 [DFU] Writing to characteristic 00001531-1212-efde-1523-785feabcd123
D 12:24:01.955 [DFU] gatt.writeCharacteristic(00001531-1212-efde-1523-785feabcd123)
I 12:24:02.127 [DFU] Data written to 00001531-1212-efde-1523-785feabcd123, value (0x): 02-00
V 12:24:02.128 [DFU] Writing to characteristic 00001532-1212-efde-1523-785feabcd123
D 12:24:02.128 [DFU] gatt.writeCharacteristic(00001532-1212-efde-1523-785feabcd123)
I 12:24:02.140 [DFU] Data written to 00001532-1212-efde-1523-785feabcd123, value (0x): 52-00-68-CE-FF-FF-FF-FF-01-00-FE-FF-8E-43
V 12:24:02.143 [DFU] Writing to characteristic 00001531-1212-efde-1523-785feabcd123
D 12:24:02.144 [DFU] gatt.writeCharacteristic(00001531-1212-efde-1523-785feabcd123)
I 12:24:02.225 [DFU] Notification received from 00001531-1212-efde-1523-785feabcd123, value (0x): 10-02-01
I 12:24:02.227 [DFU] Data written to 00001531-1212-efde-1523-785feabcd123, value (0x): 10-02-01
A 12:24:02.227 [DFU] Initialize DFU Parameters completed
A 12:24:02.227 [DFU] Response received (Op Code = 2, Status = 1)
V 12:24:02.228 [DFU] Writing to characteristic 00001531-1212-efde-1523-785feabcd123
D 12:24:02.228 [DFU] gatt.writeCharacteristic(00001531-1212-efde-1523-785feabcd123)
I 12:24:02.306 [DFU] Data written to 00001531-1212-efde-1523-785feabcd123, value (0x): 03
A 12:24:02.307 [DFU] Receive Firmware Image request sent
A 12:24:02.354 [DFU] Uploading firmware...
V 12:24:02.354 [DFU] Sending firmware to characteristic 00001532-1212-efde-1523-785feabcd123...
I 12:24:02.403 [DFU] Notification received from 00001531-1212-efde-1523-785feabcd123, value (0x): 10-03-06
A 12:24:02.403 [DFU] Response received (Op Code = 3, Status = 6)
E 12:24:02.403 [DFU] Remote DFU error: OPERATION FAILED
V 12:24:02.403 [DFU] Writing to characteristic 00001531-1212-efde-1523-785feabcd123
D 12:24:02.403 [DFU] gatt.writeCharacteristic(00001531-1212-efde-1523-785feabcd123)
A 12:24:07.500 [DFU] Reset request sent
D 12:24:07.503 [DFU] gatt.refresh() (hidden)
D 12:24:07.505 [DFU] gatt.disconnect()
D 12:24:07.507 [Broadcast] Action received: android.bluetooth.device.action.ACL_DISCONNECTED
D 12:24:07.538 [DFU] [Broadcast] Action received: android.bluetooth.device.action.ACL_DISCONNECTED
D 12:24:07.538 [DFU] gatt.close()
D 12:24:07.538 [DFU] wait(600)
D 12:24:08.134 gatt.close()
D 12:24:08.138 wait(200)
V 12:24:08.342 Connecting to E9:77:F4:87:BF:C6...
D 12:24:08.343 gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
D 12:24:38.357 [Callback] Connection state changed with status: 133 and new state: DISCONNECTED (0)
E 12:24:38.358 Error 133 (0x85): GATT ERROR
I 12:24:38.358 DisconnectedHello @flatbat, welcome to the forum.
OTA DFU is a little bit tricky. I updated the bootloader of 5 RAK4631 with 2 different phones without problems over BLE, but there is feedback from other people that it does not work for them.
The provided RAK4630_bootloader-0.4.1.hex is a valid update file. Can you check that
- the file size is 190893 bytes
- the SHA256 checksum is
C0E95AD4A7F5C5B2B750921EC3BB2D8A074E4BA585460BDF5633B969B7D7B607
to make sure that your download is not corrupted.
About the changes of the new bootloader, it solves the problem with the automatic start of the sketch and it solves a problem with the USB Serial port. So it would be good if you can update the bootloader.
Date: Jun 16 2020 shows that you have the old bootloader.
The new bootloader shows Date: Mar 31 2021 in the INFO_UF2.TXT file.
Can you try to load the following sketch into your RAK4631:
void setup() {
// Initialize Serial for debug output
Serial.begin(115200);
// On nRF52840 the USB serial is not available immediately
while (!Serial)
{
delay(100);
digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
}
Serial.println("Press 'y' key to enter DFU OTA mode");
while (!Serial.available())
{
Serial.print(".");
delay(200);
}
Serial.println("");
char c = Serial.read();
if (c == 'y')
{
Serial.println("Entering DFU OTA mode in 5 seconds");
Serial.println("Start >nRF Connect< or >My nRF52 Toolbox< and scan for a device named >AdaDFU<");
Serial.println("Connect to the device >AdaDFU< and start the DFU update.");
delay(5000);
enterOTADfu();
}
Serial.println("OTA DFU not started");
delay(200);
}
void loop() {
// put your main code here, to run repeatedly:
}
This sketch forces the RAK4631 into DFU OTA bootloader mode. If you run the sketch, the device will show as AdaDFU in nRF Connect. Then try again to flash the bootloader.
Beside of nRF Connect, did you try to flash the bootloader with My nRF52 Toolbox It is a small toolbox app that I wrote by myself.
If both methods fail, the only option to update the bootloader is with the RAKDAP1 DAPLink adapter over the SWD interface. We have a tutorial how to use it in our Documentation Center
Thanks for your weekend support…!
I tried nRF Connect and nRF Toolbox, but hadn’t realised that you were referring to a third app ‘My nRF52 Toolbox’, which didn’t appear at first in Google Play.
It looks very similar to the nRF Toolbox app, but at first hang instead of just terminating like the two others did. On a whim I switched on the first option in the settings ‘Packets receipt notification procedure’, and then it suddenly starts to upload…!
Once up again, INFO_UF2.TXT now contains:
UF2 Bootloader 0.4.1-13-g5e6690e-dirty lib/nrfx (v2.0.0) lib/tinyusb (0.9.0-22-g7cdeed54) lib/uf2 (remotes/origin/configupdate-9-gadbb8c7)
Model: WisBlock RAK4631 Board
Board-ID: WisBlock-RAK4631-Board
SoftDevice: S140 version 6.1.1
Date: Mar 31 2021
The green led is ‘breathing’, so something has changed…
Tomorrow we will continue where we left off with the original issue, and hopefully it’s all just fine now…!
Thanks again.
Hi,
breathing green LED and the date looks good. After flashing the bootloader, there is no more sketch on the RAK4631, so it stays in bootloader mode until you upload a new sketch.
I think you are good now. Let me know how it goes.
I think I need to change that option as default in the next version of ‘My nRF52 Toolbox’. Thank you for your feedback.
Hi,
It’s confirmed that the RAK4631 now starts the sketch on power-up also with a GPS-module attached, so all is good!
Thank you for the feedback.
I wish you fun with WisBlock.
Yeah, well, the target is to have a working product for production. Fun is not really a factor… 
@flatbat
We are always interested in what products our WisBlock will be used. Can you give me some details?
It’s for a customer project where we need a building platform for simple LoraWAN-based clients of different kinds. I believe the WisBlock looks like the perfect solution for non-industrial scale custom installations to get rid of all the manual labor and intermittent faults all too well related to soldering and sensors hanging in a mess of wires inside the casing. If it works out, I will share more later…
@flatbat
Thank you for the insights, what you are doing is exactly one of the ideas we had when we started WisBlock development.
Good luck with your project.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.