Where to Get Original Factory Firmware for a GPy 1.0? (release=1.10.1.b1)
-
I would like to downgrade to the original factory Pycom firmware on a GPy 1.0. I have one GPy 1.0 that has never been upgraded. It shows the release
1.10.1.b1>>> os.uname() (sysname='GPy', nodename='GPy', release='1.10.1.b1', version='v1.8.6-843-gd3b69c78-dirty on 2017-11-18', machine='GPy with ESP32')Why
This original version does not expose any LTE class undernetwork. I can connect directly with the modem via a UART and use AT commands without any LTE object messing with the modem (I assume, but would like to see the source too).u = UART(2, baudrate=921600, pins=('P5', 'P98', 'P7', 'P99')) u.write('ATI1\r\n') u.readall()Where I've Looked
Github underpycom/pycom-micropython-sigfox(link). The releases and tags only go back to something like1.11.xxxbefore the naming convention changed to things likeDEV_0.1orV0.1, etc.The firmware downgrade guide (link). The earliest
tar.gzavailable for the GPy is1.10.2.b2. I tried that version but it does not allow the direct UART connection (it has anetwork.LTEclass). -
@wgtthompson If you want the module to ignore the modem completely (though that will probably make quite a few things difficult, I don't think you would be able to use IP connectivity via the modem at all), using a WiPy firmware is probably the easiest solution.
Alternatively, just build from source and disable the LTE part, I'm pretty sure it can be done with minimal configuration (though I haven't verified this).
-
I just tried 1.18.3 and the 1.10.1.b1 firmwares for the WiPy on a GPy 1.0. The
machine.UARTclass throws aValueErrorin both of these. It appears that it does not accept theP98andP99pins. So, it appears the WiPy firmware route is not an option.>>> u = UART(2, baudrate=921600, pins=('P5', 'P98', 'P7', 'P99')) Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: invalid argument(s) value -
@wgtthompson Mmpf indeed. You would have to modify
esp32/boards/WIPY/pins.csvand rebuild. The firmware actually knows about those pins, it just doesn't seem to be able to support the directGPIO*names in thePinorUARTconstructors (if my cursory reading of the source is accurate). -
@jcaron I got a response from @robert-hh in another post that it might be possible to use
esptool.pyto read the flash from one GPy and write that copy to another GPy. Since I have a GPy with the original firmware, that may be the simplest option. It seems strange that a firmware image is not available though. -
@jcaron @robert-hh I tried to copy flash from the GPy with the original factory firmware and then write it to another GPy. This attempt failed. The GPy that the firmware was written to booted with the red LED. Any pointers on where I went wrong would be helpful.
What I Did
Instead of using theesptool.py, I used the CLI version of the Pycom updater (pycom-fwtool-cli). I created a full flash copy from the GPy with the factory/original Pycom firmware (1.10.1.b1):$ pycom-fwtool-cli.exe -p COM10 -s 921600 copy -p all Running in PIC modeall (100 %) Read 8388608 bytes at 0x0 in 382.8 seconds (175.3 kbit/s)... Partition saved to 000000000000-all.binI then wrote that file to the other GPy:
$ pycom-fwtool-cli.exe -p COM5 -s 921600 copy -p all -r -f 000000000000-all.bin Running in PIC mode000... (100 %) Wrote 8 MiB from 000000000000-all.bin in 45.12 seconds (1487.2 kbit/s)...I rebooted and the LED lit up solid red. I then did a flash erase with
esptool.py:$ esptool.py -c esp32 -p COM5 erase_flash esptool.py v2.8 Serial port COM5 Connecting...... Chip is ESP32D0WDQ6 (revision 1) Features: WiFi, BT, Dual Core, Coding Scheme None Crystal is 40MHz MAC: <REDACTED> Uploading stub... Running stub... Stub running... Erasing flash (this may take a while)... Chip erase completed successfully in 5.5s Hard resetting via RTS pin...And then wrote to flash again:
$ pycom-fwtool-cli.exe -p COM5 -s 921600 copy -p all -r -f 0000000000000-all.bin Running in PIC mode000... (100 %) Wrote 8 MiB from 0000000000000-all.bin in 45.12 seconds (1487.2 kbit/s)...The GPy still booted with the red LED. I then wrote the original copy of the flash back to it and it booted back to normal.
$ pycom-fwtool-cli.exe -p COM5 -s 921600 copy -p all -r -f 111111111111-all.bin Running in PIC mode000... (100 %) Wrote 8 MiB from 111111111111-all.bin in 51.22 seconds (1310.3 kbit/s)...Result after writing the copy of flash to the target GPy:
>>> os.uname() (sysname='GPy', nodename='GPy', release='1.20.2.rc3', version='v1.11-2037465 on 2020-02-05', machine='GPy with ESP32', pybytes='1.3.1') -
@wgtthompson Are they the same hardware version?
-
@jcaron It appears both are the same hardware version.
Both have "GPy V1.0r" screen-printed on the bottom of the board. The stickers, which I assume is some sort of serial number, differ by 5. The
chip_idreturned bypycom-fwtool-cliisESP32D0WDQ6 (revision 1)for both. -
Update: I wrote the 1.10.1.b1 flash copy from the non-updated GPy 1.0 to the target GPy, again. The same result occurred (red LED on boot). I captured it's initial output on the terminal. It matches the initial output of the non-updated GPy but never gets to the Micropython prompt.
ets Jun 8 2016 00:22:57 rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff9028,len:8 load:0x3fff9030,len:1076 load:0x4009fa00,len:0 ho 12 tail 0 room 4 load:0x4009fa00,len:15344 entry 0x400a070c
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