Updated bootloader for RAK4631

The new bootloader for the RAK4631 solves the USB problems when uploading your sketch. Different to our old bootloader, you can flash this bootloader in two different ways.
Follow these instructions to upgrade the bootloader over BLE OTA DFU
Follow these instructions to upgrade the bootloader over DAPLINK/JLink

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:
image
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 :+1:

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.
image
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.