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
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.
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.
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
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.
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).
@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ā¦
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.
@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
I agree. but even worse is, that itās not worth the hassle of upgrading, because the TTN Node hardware will not run longer after the upgrade. its a total battery drainer POS.
Is this due to the Microchip module, the SparkFun AVR or the whole power management?
I am currently also evaluating the RS1xx sensor nodeā¦but this one wants a confirmation for each uplink messageā¦havenāt had time to test their RM1xx modules.
Or which sensor node would you recommend for environmental measurements?
In the āModuleā menu select āBoot Loader Recoverā and your module should be available. For RN2483 (not A) modules the latest working firmware seems to be 1.0.3. (TTN products use the RN2483)
Isnāt loriot.io expensive to use?
At least for the community version it woul dmean that I canāt use the RS1xx nodes as they require a downlink for sending the RTC dataā¦
I use TTN due to the fact that in our country Swisscom is rather expensiveā¦
I am currently very happy with the Laird RG186 gatewayā¦no outages so far with the TTN setupā¦