Failed to install firmware on LilyGO LoRa32 v2.1 (T3 v1.6.1) 868 Mhz board

[r8io]

Hi Mark, please allow me to give you the praise that you deserve before asking for support while I try to join the TRUE internet, the RetNet :-)

I stumbled upon your work about a week ago, realizing the incredible potential. You are a truly visionary man with extraordinary capabilities and exceptional perseverance. A great example for the rest of us! Let's carry on ... with my little problem :-)

I get a warning message when I try to install the RNode firmware v1.56 on a LilyGO LoRa32 v2.1 (T3 v1.6.1) 868 Mhz board:

WARNING: Detected crystal freq 41.01MHz is quite different to normalized freq 40MHz. Unsupported crystal in use?

A fatal error occurred: Failed to write to target RAM (result was 01070000)

                               Installer Ready

Ok, that should be all the information we need. Please confirm the following
summary before proceeding. In the next step, the device will be flashed and
provisioned, so make sure that you are satisfied with your choices.

Serial port     : /dev/cu.usbmodem53230228381
Device type     : LilyGO LoRa32 v2.1 850 - 950 MHz
Platform        : ESP32
Device MCU      : Espressif Systems ESP32
Firmware file   : rnode_firmware_lora32v21.zip

------------------------------------------------------------------------------

Is the above correct? [y/N] y
[11:55:00] Checking firmware file availability...
[11:55:00] The latest firmware for this board is version 1.56
[11:55:00] Using existing firmware file: rnode_firmware_lora32v21.zip for version 1.56
[11:55:00] Verifying firmware integrity...
[11:55:00] Decompressing firmware...
Archive:  /Users/username/.config/rnodeconf/update/1.56/rnode_firmware_lora32v21.zip
  inflating: /Users/username/.config/rnodeconf/update/1.56/esptool.py  
  inflating: /Users/username/.config/rnodeconf/update/1.56/console_image.bin  
  inflating: /Users/username/.config/rnodeconf/update/1.56/rnode_firmware_lora32v21.boot_app0  
  inflating: /Users/username/.config/rnodeconf/update/1.56/rnode_firmware_lora32v21.bin  
  inflating: /Users/username/.config/rnodeconf/update/1.56/rnode_firmware_lora32v21.bootloader  
  inflating: /Users/username/.config/rnodeconf/update/1.56/rnode_firmware_lora32v21.partitions  
[11:55:00] Firmware decompressed
[11:55:00] Flashing RNode firmware to device on /dev/cu.usbmodem53230228381
esptool.py v3.1
Serial port /dev/cu.usbmodem53230228381
Connecting....
Chip is ESP32-PICO-D4 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
WARNING: Detected crystal freq 41.01MHz is quite different to normalized freq 40MHz. Unsupported crystal in use?
Crystal is 40MHz
MAC: 4c:75:25:c2:f2:58
Uploading stub...

A fatal error occurred: Failed to write to target RAM (result was 01070000)
username@usernames-macbook ~ % 

[markqvist]

Hi @r8io, thanks so much for the kind words! I really appreciate it :)

Hmm, that's weird. It looks like your board actually has a faulty or out-of-spec crystal oscillator on it, or someone was out of the proper 40MHz one, and slapped in a 41 MHz crystal instead. Either way, that's probably going to mess up the timing for the default speed the rnodeconf tries to flash the firmware at, which is about 922 Kbps.

If you lower the communications speed, it might be able to sync just fine, and flash the firmware, and if it succeeds, the firmware, once installed, should be able to account for the slight clock difference just fine.

If you're able to edit the rnodeconf tool yourself, I'd suggest to do the following. At around line 1950 in the rnodeconf.py file, you will find the following chunk of code, specifying the flasher parameters:

elif fw_filename == "rnode_firmware_lora32v21.zip":
  if numeric_version >= 1.55:
      return [
          flasher,
          "--chip", "esp32",
          "--port", args.port,
          "--baud", "921600",
          "--before", "default_reset",
          "--after", "hard_reset",
          "write_flash", "-z",
          "--flash_mode", "dio",
          "--flash_freq", "80m",
          "--flash_size", "4MB",
          "0xe000",  UPD_DIR+"/"+selected_version+"/rnode_firmware_lora32v21.boot_app0",
          "0x1000",  UPD_DIR+"/"+selected_version+"/rnode_firmware_lora32v21.bootloader",
          "0x10000", UPD_DIR+"/"+selected_version+"/rnode_firmware_lora32v21.bin",
          "0x210000",UPD_DIR+"/"+selected_version+"/console_image.bin",
          "0x8000",  UPD_DIR+"/"+selected_version+"/rnode_firmware_lora32v21.partitions",
      ]

Change the line that says "--baud", "921600", to "--baud", "115200",. The flashing will of course take a lot longer, but the lower communications rate might let the flasher succeed.

If it works, I could add a --slow option to the program, so this can be done easily, if anyone else has boards with weird crystal frequencies.

On macOS, I think you can find the rnodeconf.py file in something like /Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/RNS/Utilities/rnodeconf.py, but if not, a sudo find / -name rnodeconf.py should locate the file :)

[r8io]

Mark, thank you for the quick reply.

I found and edited the rnodeconf.py file as described but I still get an error.

A fatal error occurred: Failed to write to target RAM (result was 01070000)

                                Installer Ready

Ok, that should be all the information we need. Please confirm the following
summary before proceeding. In the next step, the device will be flashed and
provisioned, so make sure that you are satisfied with your choices.

Serial port     : /dev/cu.usbmodem53230228381
Device type     : LilyGO LoRa32 v2.1 850 - 950 MHz
Platform        : ESP32
Device MCU      : Espressif Systems ESP32
Firmware file   : rnode_firmware_lora32v21.zip

------------------------------------------------------------------------------

Is the above correct? [y/N] y
[11:55:00] Checking firmware file availability...
[11:55:00] The latest firmware for this board is version 1.56
[11:55:00] Using existing firmware file: rnode_firmware_lora32v21.zip for version 1.56
[11:55:00] Verifying firmware integrity...
[11:55:00] Decompressing firmware...
Archive:  /Users/username/.config/rnodeconf/update/1.56/rnode_firmware_lora32v21.zip
  inflating: /Users/username/.config/rnodeconf/update/1.56/esptool.py
  inflating: /Users/username/.config/rnodeconf/update/1.56/console_image.bin
  inflating: /Users/username/.config/rnodeconf/update/1.56/rnode_firmware_lora32v21.boot_app0
  inflating: /Users/username/.config/rnodeconf/update/1.56/rnode_firmware_lora32v21.bin
  inflating: /Users/username/.config/rnodeconf/update/1.56/rnode_firmware_lora32v21.bootloader
  inflating: /Users/username/.config/rnodeconf/update/1.56/rnode_firmware_lora32v21.partitions
[11:55:00] Firmware decompressed
[11:55:00] Flashing RNode firmware to device on /dev/cu.usbmodem53230228381
esptool.py v3.1
Serial port /dev/cu.usbmodem53230228381
Connecting....
Chip is ESP32-PICO-D4 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 4c:75:25:c2:f2:58
Uploading stub...

A fatal error occurred: Failed to write to target RAM (result was 01070000)
username@usernames-macbook ~ %

[r8io]

Just in case if we should run out of options for a solution. I could return the boards to the vendor. They arrived today so there shouldn't be a problem with sending them back.

[markqvist]

Ok, for what it's worth, I can confirm that the exact same issue occurs here with some of the boards I have on hand, on an old macbook I was kindly allowed to mess around with ;)

After some more digging, it seems that some of these boards come with a USB chip that doesn't work well natively in macOS versions after Big Sur. I've never had that problem myself, since I've apparently never flashed anything with that chip on macOS ;)

The manufacturer has a driver available for download here: https://www.wch.cn/downloads/CH34XSER_MAC_ZIP.html

It's all in Chinese, but at least the downloaded file has a PDF with install instructions in English ;)

The gist of it is:

• Download the zip package, and unzip it
• Dont mind the .pkg file, it's only for ancient versions of macOS
• Open the DMG file, and drag the app to your applications folder
• Open the app, click "Install driver"
• The app will load a new KEXT for the serial driver, but macOS will tell you that you must allow it to continue loading.
• Press "open system preferences", allow the driver
• That should be it

The devices with this type of chip will now show up as /dev/tty.wchusbserial* when attached. If you use one of these from rnodeconf, the flashing works perfectly :)

Some more context and info from this thread: https://github.com/Xinyuan-LilyGO/LilyGo-T-Call-SIM800/issues/139#issuecomment-1006419827

If you're up for installing a driver from a chinese chip manufacturer, you could give it a go. Otherwise, you might be able to use a Linux machine, if you have one available, or run it in a VM, which should also work fine, I'd wager a guess to that at least.

[r8io]

Issue solved! I succeed installing the firmware to the device by using Debian Linux running in a VM.

On Linux the firmware installation process runs as expected without any issues. I had to brush up my Linux skills though :-)

Nice try with the "install Chinese software" part. My Macbook makes me feel uneasy enough already :-)

Thank you so much for taking the time to help. See you on the RetNet.

[r8io]

I felt a little reckless today, so I went ahead and installed the Chinese driver as suggested above. Worked like a charm.

[markqvist]

Thanks for providing the feedback!

[faragher]

Just wanted to mention I just successfully flashed two of the same boards at default settings, but it also warned me about a 41 MHz crystal on each of them.

[r8io]

Hi faragher, interesting ... what do you get when you run rnodeconf --info /dev/tty<your-device-name>?

I did a firmware update the other day using a Debian Linux VM. No problems there. When I run rnodeconf --info /dev/tty.wchusbserial53230228381 now on my MacBook I get a Device signature validation failed message.

[faragher]

Wow. That's fascinating. Forgive the lack of copy/paste from the Kali system, but I'm getting different results based on OS.

Windows:

[03:08:13] Opening serial port com6...
[03:08:17] Device connected
[03:08:17] Current firmware version: 1.58
[03:08:17] Reading EEPROM...
[03:08:17] EEPROM checksum correct
[03:08:17] Device signature validation failed

[warning truncated]

[03:08:17]
[03:08:17] Device info:
[03:08:17]      Product            : LilyGO LoRa32 v2.1 850 - 950 MHz (b1:b9:37)
[03:08:17]      Device signature   : Unverified
[03:08:17]      Firmware version   : 1.58
[03:08:17]      Hardware revision  : 1
[03:08:17]      Serial number      : 00:00:00:01
[03:08:17]      Frequency range    : 850.0 MHz - 950.0 MHz
[03:08:17]      Max TX power       : 17 dBm
[03:08:17]      Manufactured       : 2023-02-21 18:59:40
[03:08:17]      Device mode        : Normal (host-controlled)

Kali reports identical information except the signature is validated. Now, I flashed the board using the Kali machine, but that shouldn't matter for verification, should it? Given your MacBook signature issue, I think this may be OS related.

Also, as an aside, I'm really glad I read that USB is disabled when bluetooth is on, otherwise I'd have been pretty concerned when it initially failed to respond.

[r8io]

"Also, as an aside, I'm really glad I read that USB is disabled when bluetooth is on, otherwise I'd have been pretty concerned when it initially failed to respond." Haha, I think that caught me the other day when I thought the USB connection was not working on my MacBook :-)

I just did some more testing and everything seems to work fine. I can communicate with Sideband and Nomadnet between all my devices (MacBook, Debian Linux VM on MacBook, Google Pixel 6a with GrapheneOS).

So we only seem to be dealing with the little Device signature validation failedanomaly.

[markqvist]

The Device signature validation failed is inconsequential, as long as you know that the device wasn't messed with by someone else.

It fails because you flash and sign it from one computer, and then check it on another computer that doesn't have any knowledge about the locally generate keys used to sign it with.

You can always copy the key from ~/.config/rnodeconf/firmware/signing.key to your other systems to allow verification across different devices :)

[r8io]

OK great, thank you @markqvist!

I copied the signing.key as described above for esthetic reasons :-)

Now theDevice signature is properly validated.

[faragher]

That's an excellent thing to know for management of deployed units. Thanks.