Trying to upgrade the modem to 1.5.0

I have installed MicroPython 1.9.1 on this board and now I am trying to update the modem software from 1.45 to 1.50. I have failed to do this via the the IoT Cloud Route and now trying with the new IDE (2.0) and Tools -> WiFi101 / WiFiNINA Firmware Updater .. but that is failing too .. I can select the board and the firmware (1.5.0) and then hit Install , but always end up with ...

Has anyone made this work? Any tips?

TIA.

I also tried the arduino-fwuploader route .. failed again. So is something up with the ublox module, I wonder?

C:\Users\PMolloy\Downloads\arduino-fwuploader_2.2.0_Windows_64bit>arduino-fwuploader firmware flash -b arduino:mbed_nano:nanorp2040connect -a COM14 -m NINA@1.5.0
rp2040load 1.0.1 - compiled with go1.15.8
.....................
error during sketch flashing: exit status 1
rp2040load 1.0.1 - compiled with go1.15.8
.....................
error during sketch flashing: exit status 1
rp2040load 1.0.1 - compiled with go1.15.8
.....................
error during sketch flashing: exit status 1

Hi @patmolloy excellent idea to go straight to arduino-fwuploader (that is what Arduino IDE 2.x is using under the hood anyway.

Please try running that code again, except add a --verbose flag to the command. After that, please copy and paste the output in a reply here.

You don't have to wait for the ridiculous number of retry attempts to pass. You can just do a Ctrl+C to cancel it after the first time it fails.

We all know that if it didn't succeed the first time it is not going to the second, and it is surely not going to the ninth time. I don't know what the developer was thinking by setting that retry system up :crazy_face:

Hi, thanks for the quick reply!

I'm not sure this tells us much more :confused:

> C:\Users\PMolloy\Downloads\arduino-fwuploader_2.2.0_Windows_64bit>arduino-fwuploader --verbose firmware flash -b arduino:mbed_nano:nanorp2040connect -a COM14 -m NINA@1.5.0
> INFO[0000] arduino-fwuploader Version: 2.2.0 Commit: e4b7a87 Date: 2022-05-02T15:51:55Z
> INFO[0000] Checking signature                            index="C:\\Users\\PMolloy\\AppData\\Local\\Temp\\55770067919477794101614853572\\index.json" signatureFile="C:\\Users\\PMolloy\\AppData\\Local\\Temp\\55770067919477794101614853572\\index.json.sig" trusted=true
> INFO[0000] Checking signature                            index="C:\\Users\\PMolloy\\AppData\\Local\\Temp\\fwuploader\\package_index.json" signatureFile="C:\\Users\\PMolloy\\AppData\\Local\\Temp\\fwuploader\\package_index.json.sig" trusted=true
> INFO[0000] Checking signature                            index="C:\\Users\\PMolloy\\AppData\\Local\\Temp\\fwuploader\\module_firmware_index.json" signatureFile="C:\\Users\\PMolloy\\AppData\\Local\\Temp\\fwuploader\\module_firmware_index.json.sig" trusted=true
> INFO[0002] Putting board into bootloader mode
> rp2040load 1.0.1 - compiled with go1.15.8
> .....................
> error during sketch flashing: exit status 1
> ERRO[0025] error during sketch flashing: exit status 1
> INFO[0025] Waiting 1 second before retrying...
> INFO[0026] Retrying upload (1 of 9)
> INFO[0026] Putting board into bootloader mode

I wonder if the board is really going into bootloader mode?

After copying the [blink.ino.elf.uf2 ] to the device (with the link between GND and REC) .. I remove the link and reboot and the device is on COM14.

Is that the right sequence of events?

With the link ON (between GND and REC) the device appears as a filesystem and I copy the file. In device manager it does not appear on a COM port, but I do see ..
image

Well, I may have made things worse!

I used ZADIG to load the WinUSB Driver for the board when in Boot Mode .. and now see

image

And then ran .. (putting RP2 instead of COM14)

C:\Users\PMolloy\Downloads\arduino-fwuploader_2.2.0_Windows_64bit>arduino-fwuploader --verbose firmware flash -b arduino:mbed_nano:nanorp2040connect -a RP2 -m NINA@1.5.0
INFO[0000] arduino-fwuploader Version: 2.2.0 Commit: e4b7a87 Date: 2022-05-02T15:51:55Z
INFO[0000] Checking signature                            index="C:\\Users\\PMolloy\\AppData\\Local\\Temp\\55770067919477794103391850613\\index.json" signatureFile="C:\\Users\\PMolloy\\AppData\\Local\\Temp\\55770067919477794103391850613\\index.json.sig" trusted=true
INFO[0000] Checking signature                            index="C:\\Users\\PMolloy\\AppData\\Local\\Temp\\fwuploader\\package_index.json" signatureFile="C:\\Users\\PMolloy\\AppData\\Local\\Temp\\fwuploader\\package_index.json.sig" trusted=true
INFO[0001] Checking signature                            index="C:\\Users\\PMolloy\\AppData\\Local\\Temp\\fwuploader\\module_firmware_index.json" signatureFile="C:\\Users\\PMolloy\\AppData\\Local\\Temp\\fwuploader\\module_firmware_index.json.sig" trusted=true
INFO[0001] Putting board into bootloader mode
rp2040load 1.0.1 - compiled with go1.15.8
Loading into Flash: [==============================]  100%

ERRO[0018] Serial port not found
Error during firmware flashing: Serial port not found
ERRO[0018] Error during firmware flashing: Serial port not found
Serial port not found
ERRO[0018] Serial port not found
INFO[0018] Waiting 1 second before retrying...
INFO[0019] Retrying upload (1 of 9)
INFO[0019] Putting board into bootloader mode
rp2040load 1.0.1 - compiled with go1.15.8
Loading into Flash: [==============================]  100%

ERRO[0036] Serial port not found
Error during firmware flashing: Serial port not found
ERRO[0036] Error during firmware flashing: Serial port not found
Serial port not found
ERRO[0036] Serial port not found
INFO[0036] Waiting 1 second before retrying...
INFO[0037] Retrying upload (2 of 9)
INFO[0037] Putting board into bootloader mode

Which looked like it might have worked from the 100% on the Flash message, but I still get this error ..

Traceback (most recent call last):
  File "<stdin>", line 8, in <module>
OSError: Firmware version mismatch. Minimum supported firmware is v1.5.0 found v1.4.5

Yes, the

rp2040load 1.0.1 - compiled with go1.15.8
Loading into Flash: [==============================]  100%

message is a bluff - Putting any old rubbish after the -a option gives this ..

Is this something to do with the .uf2 file not being compatible with the actual flash chip on the board? There are some threads about this floating around ...

Hi @patmolloy. I apologize for not being very responsive. I have been doing some experimentation with my board but so far was unable to reproduce the problem. This is usually the first step in my approach to troubleshooting and support so I got a bit slowed down.

It is possible. I was thinking about this exact problem:

Does the flash chip on your board say "ISSI" or "adesto"?


No problem. This is not super urgent, obvs, but would be great to get it working!

It's the adesto chip on this board.

OK, that is the one I have on my boards as well (the boards with the ISSI chip were only a limited run and I didn't manage to add one to my collection).

As mentioned in RP2040 Connect board has faulty components in newest purchase · Issue #318 · arduino/ArduinoCore-mbed · GitHub, the boards with the ISSI chip were the ones giving people problems. So the fact you have the adesto chip makes me less suspicious that it is flash chip related.

So, I got ahold of a fresh board. Fired up IDE 2.0 and was immediately able to update to NINA 1.5.0.

And successfully compiled and am running one of the demo WiFi Scripts.

I then put the board into bootloader mode to try installing 1.9.1 MicroPython by copying the .uf2 onto the board. It apparently worked and the board reboots, but no REPL.

And at this point the board is still working in the 2.0 IDE, however.

So I guess I am just confused now :slight_smile:

What are the steps to get this board playing nice with IDE 2.0 and separately MicroPython?

Ok, I have sorted this out now. Both boards on 1.5.0, both working with IDE 2.0 or MicroPython.

I think this was down to me missing/messing up a step -- when putting the board into bootloader mode by grounding REC, you must remove the ground before copying the .uf2 file over - maybe I just missed that somewhere in the docs.

Following this procedure and copying the [blink.ino.elf.uf2] to the device, does enable the device to be seen and NINA updated to 1.5.0 in the 2.0 IDE (or via the updater).

I'm very glad you were able to find the solution @patmolloy. Thanks for taking the time to post an update with your solution!

Thanks so much for all your help. It enabled me to track down the problem in the end!

1 Like

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.