LOPY - No more REPL by USB after upgrade



  • Hello, i just made a upgrade of two LOPY. I have use the pycom_firmware_update_1.1.2.b2 for flash them both (and i have this version printout at reset: MicroPython v1.8.6-820-g56004e13 on 2017-11-08; LoPy with ESP32). But on both after reset without the wire between G23 and GND i can not use the screen command on the /dev/ttyUSB to send and receive command. But with telnet this will work (and i see the right result with USB by screen command). I havn't made change on the computer, and if i use a lopy wich are not have been update, the REPL is available.

    I have fast search if the problem is become to anyone other, but i can't find that. What solution i can try to have the REPL on USB please? Thank's



  • @keithmarsh said in LOPY - No more REPL by USB after upgrade:

    @robert-hh No, but I'm happy to press on with 9. It's my first few days with the WiPy, and I'm eager to have some fun, so happy to wait. Shorting the pins on a PySense is also a bit of a pain - I don't have an Expansion Board 2.0 (yet).

    The firmware is still under development. The firmware of the PyTrack has two leading zeros. There will be a lot of usefull updates. I suggest to solder a switch on The LoPy dev board. Invest 5 minutes and your life will be much nicer. I have to do this for the PyTrack as well. It is no fund to close every time the offical case, when the case has neither a suitable cable management nor matching fix point for the sensor boards.



  • @robert-hh No, but I'm happy to press on with 9. It's my first few days with the WiPy, and I'm eager to have some fun, so happy to wait. Shorting the pins on a PySense is also a bit of a pain - I don't have an Expansion Board 2.0 (yet).
    Thanks for your help.
    Keith



  • @keithmarsh Did you try the modifications to the updater suggested by @daniel at the top of this post: https://forum.pycom.io/topic/2097/new-firmware-release-1-10-0-b1-external-4mbyte-ram-support



  • @robert-hh Thanks Robert. Unfortunately, after the erase_flash, using the Windows Pycom Firmware Updater always yields the error shown in the image. If I wipe again, and upload 1.10.0.b1.tar.gz, the output loops, then needs input for every four characters or so. Going back to 9 and waiting for a fix. Edit: 9 works fine again.

    0_1510499017392_2017-11-12 14_54_32-Pycom Upgrade.png

    C:\Program Files (x86)\Pycom\Pycom Firmware Update\Python27\pyupgrade9>esptool.py --port COM3 --baud 230400 --chip esp32 erase_flash
    esptool.py v2.1
    Connecting....
    Chip is ESP32D0WDQ6 (revision 0)
    Uploading stub...
    Running stub...
    Stub running...
    Changing baud rate to 230400
    Changed.
    Erasing flash (this may take a while)...
    Chip erase completed successfully in 7.1s
    Hard resetting...

    C:\Program Files (x86)\Pycom\Pycom Firmware Update\Python27\pyupgrade9>..\python.exe bin\updater.py -t \Users\KeithM\Downloads\WiPy-1.10.0.b1.tar.gz -s 230400 -p COM3 flash
    Connecting......
    Uploading stub...
    Running stub...
    Stub running...
    Changing baud rate to 230400
    Changed.
    Auto-detected Flash size: 4MB
    Flash params set to 0x022f
    Compressed 14272 bytes to 9291...
    Wrote 14272 bytes (9291 compressed) at 0x00001000 in 0.4 seconds (effective 269.3 kbit/s)...
    Hash of data verified.

    Leaving...
    Auto-detected Flash size: 4MB
    Compressed 3072 bytes to 133...
    Wrote 3072 bytes (133 compressed) at 0x00008000 in 0.0 seconds (effective 1638.4 kbit/s)...
    Hash of data verified.

    Leaving...
    Auto-detected Flash size: 4MB
    Compressed 1177264 bytes to 777238...
    Wrote 1177264 bytes (777238 compressed) at 0x00010000 in 35.1 seconds (effective 268.1 kbit/s)...
    Hash of data verified.

    Leaving...
    C:\Program Files (x86)\Pycom\Pycom Firmware Update\Python27\pyupgrade9>

    Connecting on COM3...
    4
    load:0x4009fa00,len:13232
    entry 0x400a04e8
    MicroPython v1.8.6-820-g56004e13 on 2017-11-08; WiPy with ESP32
    Type "help()" for more information.

    drv:0x00,hd_drv:0x00,wp_drv:0x00
    mode.6-820-g56004e13 on 2017-11-08; WiPy with ESP32
    Type "help()" for more information.

    drv:0x00,hd_drv:0x00,wp_drv:0x00
    mode.6-820-g56004e13 on 2017-11-08; WiPy with ESP32
    Type "help()" for more information.

    drv:0x00,hd_drv:0x00,wp_drv:0x00
    mode:DIO, clock div:1
    load:0x3fff9028,len:8
    load:0x3fff9030,len:932
    load:0x4009fa00,len:0
    ho 12 tail 0 room 4
    load:0x4009fa00,len:13232
    entry 0x400a04e8
    MicroPython v1.8.6-820-g56004e13 on 2017-11-08; WiPy with ESP32
    etc etc



  • @jjarven There is already a dupterm() in the frozen _boot.py, so it's not needed in boot.py. Besides that, the error has been noticed and pycom is working on it.



  • @robert-hh Oh yes.
    In 1.9.2.b2 dupterm() in boot.py works.
    In 1.10.0.b1 (current version?) dupterm() in boot.py does not work.



  • @keithmarsh The problem is in most cases caused by a duplicate dupterm() command in both _boot.py and boot.py. because of that, all of the fowlloing methods work:
    a) erase flash and reflash the firmware.
    b) delete boot.py (which is done by a too). In order to do that, you can connect by telnet or do a safeboot.)
    Safeboot just ignores boot.py and main.py on booting.



  • I can confirm this just happened to me with my new WiPy upgraded to 1.10.something. Pressing reset showed output on the console, but I couldn't type anything in. It had been working on it's out the box firmware 0.7.something.

    Following this article
    https://forum.pycom.io/topic/517/downgrading-firmware-advanced-users
    with the command below did the trick to resurrect input.

    c:\Program Files (x86)\Pycom\Pycom Firmware Update\Python27\pyupgrade>..\python.exe bin\updater.py -t \Users\KeithM\Downloads\WiPy-1.9.2.b2.tar.gz -p COM3 -s 921600 flash

    Be good to know when this is fixed please Pycom. It wasn't a great new user experience.

    Thanks

    Keith



  • I have done just like @thibault. USB serial was working before update, not after.

    Starts working, if I use previous firmware (using this
    https://docs.pycom.io/chapter/toolsandfeatures/bootmodes.html )

    After next reboot device uses new (nonworking) firmware.

    New: v1.8.6-820-g56004e13 on 2017-11-08; LoPy with ESP32
    Old: v1.8.6-237-g9d21f17 on 2016-12-15

    EDIT:
    Working, new-ish firmware can be found here:
    https://forum.pycom.io/topic/517/downgrading-firmware-advanced-users
    FW version 1.9.2.b2, MicroPython v1.8.6-796-g489fafa0 on 2017-10-15



  • I have try your code, but the problem remain. So i have follow you tip for erase flash with your answer in this page [SOLVED]LoPy Bricked, RED LED

    On Debian, i have done:

    pip3 install esptool
    esptool.py --port /dev/ttyUSB2 --baud 230400 --chip esp32 erase_flash
    pyupgrade/update #<= for flash the update image for LOPY
    

    And before i have get backup of the file in the /flash directory. Now i have right the keyboard by the USB. So thank you. And have a nice day.

    P.S.: in the boot.py file from backup of this lopy i have this:

    # boot.py -- run on boot-up
    import os
    from machine import UART
    uart = UART(0, 115200)
    os.dupterm(uart)
    


  • @thibault in the telnet session, try:

    import os
    from machine import UART
    os.dupterm(UART(0, 115200))

    If USB REPL then works, there is a problem with the frozen _boot.py. Then I would do a flash erase and firmware reload. Since that rebuilds the file system, you might habe to save files from the device.

    Edit: The first part of this hint is wrong. There is a bug with multiple calls of dupterm.


 

Pycom on Twitter