WiPy 2.0 Firmware update - bricked and recovered

[arikb]

Hello all,

My firmware update story is a little different. When I tried to connect to the WiPy 2, I got to the REPL but reading the documentation it seems like upgrading is mandatory. Okay!

I've downloaded pycom_update_0.9.2.b2a.tar.gz today and tried to use it to upgrade the firmware. Unfortunately, after going through the motions it gives me the error message:

The upgrade failed!
Please check the connections and try the steps again

O...kay. Tried booting again... no heartbeat. Something's wrong.

Connected miniterm, and it gave me:

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
Falling back to built-in command interpreter.
OK

Well now, that can't be good. The "built-in command interpreter" seems to implement some version of BASIC, so that's a bit of a win on the nostalgia front. So I looked through the update shell script. It seems to be running this python program and discarding its output. That's no good, let's run it manually:

$ python bin/updater.py --port /dev/ttyUSB0 --file firmware/wipy_0.9.2.b2.bin 
Namespace(file='firmware/wipy_0.9.2.b2.bin', port='/dev/ttyUSB0')
Connecting...
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 115200
Changed.
Erasing flash...

[ cut some output that totally looks like it's doing its business]

Verifying just-written flash...
Verifying 0x1000 (4096) bytes @ 0x00001000 in flash against /home/tech/projects/wipy-connect/pyupgrade/bin/../firmware/bootloader.bin...
-- verify OK (digest matched)
Verifying 0x100 (256) bytes @ 0x00004000 in flash against /home/tech/projects/wipy-connect/pyupgrade/bin/../firmware/partitions.bin...
-- verify OK (digest matched)
Verifying 0x96a90 (617104) bytes @ 0x00010000 in flash against firmware/wipy_0.9.2.b2.bin...
-- verify OK (digest matched)

Booting again - got the heartbeat back and everything is normal, latest firmware installed.

So, my main complaint is - we have a 248 lines shell script that has an external dependency (dialog on my Linux machine) and hides away what's really happening, while the real work is done by a python script with properly verbose output that only receives 2 trivial parameters and actually does the work when run standalone. I don't know about everyone else, but from my perspective using the updater shell script was a waste of time, that could have been eliminated by documenting the actual python script.

</rant>

[abilio]

Yeah @arikb, you're certainly right that the feedback from the script is actually valuable. In future versions we will try to make it appear in the results.

[arikb]

@abilio I can confirm that the b version corrects the problem.

My main gripe with the UI is that it's hiding the programmer's output (> /dev/null 2>&1). I mean, in consumer product terms, WiPy 2.0 is at the alpha stage (missing features). Things are expected to change, fail and have documentation gaps. Creating a UI that hides the output of important functionality, not even dumping it to a log file is counter-productive IMO. Then it detects failure and offers a possible solution ("Please check the connections and try the steps again") which focuses the user on checking the connection without diagnosing the actual problem. I fell for it, trying different USB cables several times until I gave up and dug into the code.

Let's put this in perspective, it's not the end of the world. A competent person will probably go through the steps I did and figure it out within 15 minutes. I just don't think it's the "right thing to do".

[abilio]

@arikb, The issue you reported was caused by a typo in the version declaration of the shell script. It should be fixed from version 0.9.2.b2b onwards.

If you can try it and post your feedback here, it will be highly regarded.

Thanks,
Abilio

PS: I totally understand your point of view as an experienced user. Simplicity and full control is always better when you know what you're doing. But I also want to tell that we're trying to create tools that are easy to use even for non tech-savvy users. The dialogs are a nice way to interact with the user in simple, short steps. This is even more important for the LoPy boards, where a different firmware version must be used depending on the country standards.