HowTo: Update RN2483 Firmware on 'The Things Node'

Finally got around flashing my TTN UNO after more then two years of using it. Was still using FW 0.95 without even an OTAA function.

Instructions are ok, but didn’t work on my macbook with parralels and W10. Bricked the UNO/RN2483, but could revive it with a ftdy to the serial port on the Leonardo and the reset option in the loradevutil. Did have to lower bitrate to 9600bps to get it working though.

IMG_2616
Advice is to lower bitrate for FW update to minimize risk of errors.

1 Like

worked for me, upgraded to 1.0.3, thanks for the receipt!

I had a similar issue. The LoRa Development tool was connecting to a Bluetooth serial port. Disabling it in Device Manager and restarting the dev tool allowed me to complete the instructions

Hmmm well it seems that the firmware update messed something up. Prior to the update my node was running the Basic sketch and sending data to my gateway. After updating and reloading the sketch I am stuck with the green LED on and serial monitor reports:

Sending: mac join otaa
Response is not OK: no_free_ch
Send join command failed

I am a US user and have freqPlan TTN_FP_US915 defined. Using the same appEui and AppKey before the update

On reset I get the following messages:

– TTN: JOIN
Model: RN2483
Version: 1.0.3
Sending: mac set deveui 0004A30B001C5396
Sending: mac set adr off
Sending: mac set deveui 0004A30B001C5396
Sending: mac set appeui 70B3D57ED00091F4
Sending: mac set appkey 34F06DD7926AB3B5181F9E2EF110E471
Sending: mac save
Sending: mac set ch status 0 off
Sending: mac set ch status 1 off
Sending: mac set ch status 2 off
Sending: mac set ch status 3 off
Response is not OK: invalid_param
Sending: mac set ch status 4 off
Response is not OK: invalid_param
Sending: mac set ch status 5 off
Response is not OK: invalid_param
Sending: mac set ch status 6 off
Response is not OK: invalid_param
Sending: mac set ch status 7 off
Response is not OK: invalid_param
Sending: mac set ch status 8 on
Response is not OK: invalid_param
Sending: mac set ch drrange 8 0 3
Sending: mac set ch status 9 on
Response is not OK: invalid_param
Sending: mac set ch drrange 9 0 3

Sending: mac set ch status 71 off
Response is not OK: invalid_param
Sending: mac set pwridx 5
Sending: mac set retx 7
Sending: mac set dr 3
Response is not OK: invalid_param

I’ve been reviewing Microchip’s site and it looks like I should have used the RN2903 firmware since I am located in the US. I won’t be able to test until I get home tonight

I tried to follow the instructions in this thread with a Marvin node. The passthrough program worked fine.

When I ran the LoRa development utility it found the Marvin board fine, and I tried uploading the hex firmware file. However, somewhere in the process it encountered a “communications error”. Perhaps because the passthrough code expects 115200 baud and the firmware uploader was set at 57600. Well anyway, it stopped without completing the upgrade.

The LoRa Development Utility cannot find the MicroChip firmware anymore. Even stopping the utility, unplugging the Marvin, re-inserting it and restarting it: no RN2483 MicroChip signature.

I then hooked it up to the Serial Monitor… when I now submit sys reset or mac get deveui I get weird characters copied back. I have the idea that the MicroChip is in some kind of firmware update mode, stuck. Has anyone experienced this before? Any idea on how to get out of this to resume firmware flashing?

I’m not going to update any of my other Marvin’s or TTN Node until I know more :disappointed_relieved:

@mrme How did you revive the RN2483 exactly ? Mine’s bricked too, hardware reset doesn’t seem to work

Used a standard ftdi adapter to the serial pins of the rn2483. Powered board through usb and used the loradevutil reset option to revive the chip on 9600bps. See previous picture for the pinout to the ttn uno.

try to change baudrate in the passtrough program.

I tried pretty much all of the usual ones… 9600, 19k2, 38k, 57.6… no joy so far. I keep getting backward question marks. I’ve added code to do a hardware reset (no joy), to try and fix the auto-baud (no joy).

I’ve ordered Pickit programmer from AliExpress and am using my backup (un-upgraded) second Marvin node and the TheThingsNode… and I have 2 more TTN Uno’s of course.

I just did not like the flakiness of the LoRa development utility… it gave communications errors on all COM ports, and I’m not that familiar with Windows any more these days…

i had exactly the same issue after the microchip upgrade tool did not finish successful after 1st try of flashing. Afterwards it did not detect the RN module any more. :open_mouth:

But i could fix this by setting baud rate between node an RN module to 57600 bps in the arduino code. Then in 2nd try flashing was successful and now the module reports v1.0.3

Today I verified operation of my TTN Node. After the firmware update my Things Node is still running: 9 days in a row:
afbeelding
This is the battery voltage of the Things Node on Cayenne

I messed about with the Lora Development Utility from MicroChip on a Linux box today (as I’m not really familiar with Windows anymore). My advice… don’t bother. It’s a 32 bits program, trying to run on a 64 bits machine. It does not detect any serial ports. It is crap…

So… still one dead Marvin, on Marvin at 1.0.1, a power hungry The Things Node… and a few unused TTN Uno’s…

Actually, are you sure that is that good ? I’ve been using a Node 1.0.1 “wardriving” for a bit (I did switch off the motion detection and only did the 5 minute sending an whenever I push a button) and after 2 days of that it also was at 3.9 volts…

An update on my firmware update troubles (including a bricked Marvin). I found an older copy of the Lora Dev Utility (version 1.0 beta) that was much more reliable under Windows, and had no communications errors.

Using that, and the latest firmware version (1.0.3) I was able to restore the bootloader on the bricked Marvin, and then install firmware version 1.0.3.

I did set all the baud rates at 57600, in the PassThrough code and in the utility.

At the link below there is a ZIP file containing the firmware version that was succesful for me.

Lora Development Utility 1.0 Beta

The tools works only on windows, but the windows can be in Virtualbox running on a mac (remember that microsoft provide virtualbox image to test IE Edge, so you can boot a recent windows easily).

Just tested it with success from my macbook.

1 Like

no problemo … just install the latest dev utill

noproblemo
this is my combination that works under win 10

@BoRRoZ I tried the latest DevUtility first and this and the beta version crash with the same error. The Serial USB device driver is from Microsoft, dated 21.06.2006, version 10.0.16299.15. Driver update says: best driver already installed…
I have opend a Microchip support case. There is also a 69K java error log created which I dont feel to post here…

C:\Users\Hanspeter\Microchip\LoRaSuite\Applications\LoRaDevUtility>java -jar LoRaDevUtility.jar

Trying to Connect: COM5
A fatal error has been detected by the Java Runtime Environment:#
EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000007110b5db, pid=7764, tid=4196

JRE version: Java™ SE Runtime Environment (9.0+11) (build 9.0.4+11)
Java VM: Java HotSpot™ 64-Bit Server VM (9.0.4+11, mixed mode, tiered, compressed oops, g1 gc, indows-amd64)
Problematic frame:
C [jSSC-2.8_x86_64.dll+0xb5db]

No core dump will be written. Minidumps are not enabled by default on client versions of Windows

An error report file with more information is saved as:
C:\Users\Hanspeter\Microchip\LoRaSuite\Applications\LoRaDevUtility\hs_err_pid7764.log

If you would like to submit a bug report, please visit:
Crash Report
The crash happened outside the Java Virtual Machine in native code.
See problematic frame for where to report the bug.

C:\Users\Hanspeter\Microchip\LoRaSuite\Applications\LoRaDevUtility>

its definitely something on your side.

check these and/or reinstall https://docs.oracle.com/javase/9/install/installation-jdk-and-jre-microsoft-windows-platforms.htm#JSJIG-GUID-61460339-5500-40CC-9006-D4FC3FBCFC0D

@BoRRoZ Yes, it is/was. Uninstalled two java versions and reinstalled the offline downloada version 8.161 64bit version and installed. The gui now shows up and detects: RN2483 1.0.1 Dec 15 2015 09:38:09 created. Hopefully the update will now work. Thanks…

update: it worked, now I have: RN2483 1.0.3 Mar 22 2017 06:00:09 created

3 Likes