Where to Get Original Factory Firmware for a GPy 1.0? (release=1.10.1.b1)

[wgtthompson]

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 release1.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 under network. 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 under pycom/pycom-micropython-sigfox (link). The releases and tags only go back to something like 1.11.xxx before the naming convention changed to things like DEV_0.1 or V0.1, etc.

The firmware downgrade guide (link). The earliest tar.gz available for the GPy is 1.10.2.b2. I tried that version but it does not allow the direct UART connection (it has a network.LTE class).

[wgtthompson]

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

[wgtthompson]

@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_id returned by pycom-fwtool-cli is ESP32D0WDQ6 (revision 1) for both.

[jcaron]

@wgtthompson Are they the same hardware version?

[wgtthompson]

@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 the esptool.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.bin

I 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]

@jcaron I got a response from @robert-hh in another post that it might be possible to use esptool.py to 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]

@wgtthompson Mmpf indeed. You would have to modify esp32/boards/WIPY/pins.csv and rebuild. The firmware actually knows about those pins, it just doesn't seem to be able to support the direct GPIO* names in the Pin or UART constructors (if my cursory reading of the source is accurate).

[wgtthompson]

I just tried 1.18.3 and the 1.10.1.b1 firmwares for the WiPy on a GPy 1.0. The machine.UART class throws a ValueError in both of these. It appears that it does not accept the P98 and P99 pins. 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

[jcaron]

@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).