New WiPy 2.0 and LoPy Firmware released (version: 0.9.1.b1)
-
As @blinkenjim said, in order to use the updater manually the correct command would be:
python2 ./updater.py -f ../firmware/lopy_0.9.1.b1_868.bin --ip 192.168.4.1 --verify -r 0.9.1.b1It's important to pass the release number with
-rso that the verification can take place. -
Hi,
We have tried to get this update to work on 5 boards of which two have upgraded OK.
Using the Windows upgrader it fails every time - with either a bland 'Upgrade failed' or 'wrong board type'. We managed after a great deal of trouble to get the 0.9.0.b2 upload, but this version 0.9.1.b1 seems to be refusing. We have also tried using FTP and copying across lopy_0.9.1.b1_915.bin to appimg.bin.
Following numerous resets, restarts etc it still comes up as using version '0.9.0.b2' when we use os.uname().release
Any ideas for a consistent route for upgrading, this seems to be a huge waste of time when we want to get on with development and working out the capabilites of the product.
-
@daniel The problem is not the failure of the verification, it is the failure of the update operation.
Adding the version number does not help in upgrading the board, but it makes it clearer indeed that it did not work:
% python2 ./updater.py -f ../firmware/lopy_0.9.1.b1_868.bin --ip 192.168.4.1 --verify -r 0.9.1.b1 -b "LoPy with ESP32" Connected via Telnet, trying to login now Telnet login succeeded, lets check the git tag Board name OK FTP connection established Login successful Entered '/flash/sys' directory Firmware image found, initiating transfer... File transfer complete Connected via Telnet, trying to login now Telnet login succeeded Reset performed Waiting for the WiFi connection to come up again... Connected via Telnet, trying to login now Telnet login succeeded, lets check the git tag Error: verification failed, the release version doesn't matchAfter this:
>>> import os >>> os.uname().release '0.9.0.b2'I still cannot upgrade the board.
-
Hello,
The upgrade problems are caused by a bug in Espressif's IDF that is causing the flash memory of the module to be write protected. Espressif is working to provide a permanent solution for this as soon as possible. In the meantime they have given us a temporal way to solve it. The procedure is the following:
Download this tool which needs to be executed as:
python flash_debug.py /dev/ttyUSB0 write 0x0 2
(/dev/ttyUSB0 will have to be replaced by the actual serial port on your system)
Running the tool requires a serial connection to the module, Python 2 and Pyserial installed on your computer. The easiest way is via the expansion board. If an expansion board is not available then any USB-to-serial converter will work. The connection must be made on pins P0 (WiPy/LoPy RXD) and P1 (WiPy/LoPy TXD). Before running the tool, connect a cable jumper between GND and P2 (G23 on the expansion board), then reset the module and run the command. The total steps are:
- Connect the WiPy/LoPy via the serial port to your computer.
- Connect a cable jumper between GND and P2 (G23 on the expansion board).
- Reset the board.
- Run the command outlined above (python flash_debug.py /dev/ttyUSB0 write 0x0 2) and remember to pass the actual serial port on your system.
- Power cycle the WiPy/LoPy.
- Run the firmware update tool.
We apologize for this issue but is completely out of our control. This is happening with all ESP32 based boards. I expect a solution from Espressif within a few days. Once that's done we will release a special firmware upgrade that will also install a new bootloader.
For the firmware release next Tuesday we will integrate this unlock process in the firmware update to avoid any more manual steps.
-
-
@daniel Thanks for working on this. However, I couldn't make it to work although the various steps look ok (except for the, well, flashing one). Note that the flash is not completely locked for me, as I can update files in
/flashand have them persist a reset or a power cycle.Concerning the procedure outlined in your post:
- Connection done.
- Wiring done (as seen by the success of step 4)
- Reset done (as seen by the success of step 4)
% python2 flash_debug_tool/flash_debug.py /dev/ttyUSB0 write 0x0 2 Connecting... value: 0x0 length: 2 write 0x60002008 0x00000000 0x00400000 write 0x60002010 0x00000000 0x00000000 write 0x60002000 0x08000000 0xffffffff write 0x60002008 0x00000000 0x00400000 write 0x60002010 0x00000000 0x00000000 write 0x60002000 0x08000000 0xffffffff write 0x60002008 0x00000000 0x00400000 write 0x60002010 0x00000000 0x00000000 write 0x60002000 0x08000000 0xffffffff write 0x60002008 0x00400000 0x00400000 write 0x60002010 0x00000000 0x0000ffff write 0x60002000 0x04000000 0xffffffff write 0x60002008 0x00000000 0x00400000 write 0x60002010 0x00000000 0x00000000 write 0x60002000 0x08000000 0xffffffff get status: 0x0 ESP DEV DISCONNECT...- Power cycle done by unplugging the USB port for 5 seconds (tried the following with both regular or safe mode settings).
% python2 ./updater.py -f ../firmware/lopy_0.9.1.b1_868.bin --ip 192.168.4.1 --verify -r 0.9.1.b1 -b "LoPy with ESP32" Connected via Telnet, trying to login now Telnet login succeeded, lets check the git tag Board name OK FTP connection established Login successful Entered '/flash/sys' directory Firmware image found, initiating transfer... File transfer complete Connected via Telnet, trying to login now Telnet login succeeded Reset performed Waiting for the WiFi connection to come up again... Timeout while connecting via telnet, retrying... Connected via Telnet, trying to login now Telnet login succeeded, lets check the git tag Error: verification failed, the release version doesn't matchStill on
0.9.0.b2. -
@oneeyed if you can write files to flash that persist a power cycle then you have a different problem. It seems that for some reason the file transfer doesn't complete properly and therefore the firmware verification fails when the bootloader reboots.
import os os.mkfs(`\flash`)and then trying all over again?
Another way to do this manually:
- Connect to the lopy-wlan-xxxx network.
- Rename the firmware binary file to appimg.bin
- From where the appimg.bin file is located do on the command line:
ftp 192.168.4.1 ftp> passive ftp> cd flash ftp> cd sys ftp> put appimg.binWait until the transfer completes and reboot.
-
@daniel It did not help, although everything looked fine:
- Confirm that the flash is not totally write-locked by writing a persisted file to it:
>>> f = open("/flash/persisted-file.txt", "w") >>> f.write("This is a persisted file\n") 25 >>> f.close() >>> import machine >>> machine.reset() […reboot…] >>> import os >>> os.listdir("/flash") ['main.py', 'sys', 'lib', 'cert', 'boot.py', 'persisted-file.txt'] >>> open("persisted-file.txt").read() 'This is a persisted file\n'- Reformat the
/flashfilesystem and check that it gets repopulated from scratch after reset:
>>> import os >>> os.mkfs("/flash") >>> os.listdir("/flash") [] >>> import machine >>> machine.reset() […reboot…] >>> import os >>> os.listdir("/flash") ['main.py', 'sys', 'lib', 'cert', 'boot.py']- Upload the file (renamed from
lopy_0.9.1.b1_868.bin) to/flash/sys(as expected, the file does not appear afterwards):
% ftp 192.168.4.1 Connected to 192.168.4.1. 220 Micropython FTP Server Name (192.168.4.1:sam): micro 331 Password: 230 Remote system type is UNIX. Using binary mode to transfer files. ftp> passive Passive mode on. ftp> cd flash 250 ftp> cd sys 250 ftp> put appimg.bin 227 (192,168,4,1,7,232) 150 426 637568 bytes sent in 13.7 seconds (45.5 kbytes/s) ftp> dir 227 (192,168,4,1,7,232) 150 226- Reset the board and check that it has not been updated properly:
>>> import os >>> os.uname() (sysname='LoPy', nodename='LoPy', release='0.9.0.b2', version='f5444c7 on 2016-10-12', machine='LoPy with ESP32') -
There's something not going well with the file transfer:
637568 bytes sent in 13.7 seconds (45.5 kbytes/s)It should not take more than 4 or 5 seconds to transfer the whole image. Can you try with a different computer? Do you get the same result after doing a safe boot?
-
@daniel The transfer time seems to be due to ArchLinux's default FTP client (from GNU inetutils). Running Debian's default FTP client (from Linux netkit) leads indeed to transfer times between 3.8s and 4.9s.
However, this still does not help with getting the version on board. Can you confirm that the checksum for the 868MHz version is correct?
% md5sum /tmp/appimg.bin lopy_0.9.1.b1_868.bin ce48656f828f652b04d608d763d3a08e /tmp/appimg.bin ce48656f828f652b04d608d763d3a08e lopy_0.9.1.b1_868.bin(side note: I also tried flashing the 915MHz version and got the same result: no update)
-
@daniel The flash update fixed my problems. I was immediately able to upgrade my firmware using the python update script. Thanks for getting the fix to us.
-
@oneeyed Hi, I am having the same trouble as oneeyed. The first stage using the flash_debug.py has been completed once I installed the correct version of python (2.7) and removing all jumpers expect tx and rx.
But whatever I try I am unable to upgrade the firmware. I am firmly stuck on 0.9.0b2. I have lopy and the expansion board v2.1.
thank you
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login