Updating device FW with Pytrack 2.0X

[kevin]

Updating the device firmware on a GPy plugged into a Pytrack 2.0X board is failing, no matter which method is used. For example, using pycom-fwtool-cli to erase the flash, I get the following:

Running in PIC mode
Erasing the board can take up to 40 seconds.
Connecting to ESP32 with baudrate: 921600
Product ID: 19 HW Version: 6 FW Version: 0.0.15
Connecting........_____....._____....._____....._____....._____....._____....._____....._____....._____....._____
Exception: Failed to connect to ESP32: Invalid head of packet ('e')

Trying to load a FW image using the fwtool or via 'make flash' results in this same Exception. With the same GPy on an Expansion Board 3.0, there is no issue with either method.

Does the Pytrack 2.0X require grounding a certain pin for this to work, or some other workaround?

[kevin]

@robert-hh Ok, I'll ignore the device ID, I didn't realize that applied only to updating the board FW.

When grounding P2 and resetting, I only ever get the message I posted earlier, never the one you captured. That is the case under Windows or Linux, although the pycom-fwtool does work under Windows for me when connected to the Pytrack 2.0X. (It works under both OS when using Expansion Board 3.0/3.1.)

Thanks for your time, but I guess I will just switch to Windows for FW updates while working with the Pytrack.

[robert-hh]

@kevin If you connect P2 to GND and push the reset button on the GPY, while P2 still connected to GND to you should get the following message on a terminal:

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download

The device ID does not matter when updating the GPY firmware. The pytrack board should still only work as USB/UART bridge. Only when changing the pytrack board firmware itself, a different device ID comes into play.
Since you have trouble with Linux, it might be that some other code is dealing with the device, like a modem manager.

[kevin]

@robert-hh Ok, thank you for that clarification. Still, with that pin grounded I do not see any change in the device ID after reset:
Bus 001 Device 025: ID 04d8:f013 Microchip Technology, Inc.

Also, the serial output continually repeats the same sequence:

ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0xb (HSPI_FLASH_BOOT)
flash read err, 1000
ets_main.c 371

Does that indicate anything? Thanks for your help, if this is a unique case, I'll just blame it on the Linux VM usb drivers and move on.

[robert-hh]

@kevin Yes, G23 is also connected to the RGB LED
And no, you have to push the reset button on the GPY

[kevin]

Another update: pycom-fwtool running under Windows is working fine. Normally I run everything under a Linux VM, and that appears to be the problem here. I suspect it has to do with how the VM "captures" the USB device, which is somehow interfering with the upgrade tools.

Strange I've never had an issue with the Expansion Board 3.0/3.1 (this is the first time trying with Pytrack 2.0X) - I guess there is a difference in USB-to-serial design across these boards? Probably not worth spending any more time on it anyway.

[kevin]

@robert-hh Thank you for the suggestions. However, it does not appear that grounding G23 puts the device into bootloader mode for me. Just to make sure, G23 is also labelled as RGB_LED on the pinout, correct? And I should push the reset button on the Pytrack (labelled MCLR), not the GPy reset button?

After doing that, the USB device ID did not change:
Bus 001 Device 009: ID 04d8:f013 Microchip Technology, Inc.

If I understand correctly, in bootloader mode this would be 04d8:f014. For example, if I hold MCLR while powering up the module, the ID will read f014 for a short time (about 7 seconds) but not long enough to try flashing the module.

Thanks again for any advice.

[robert-hh]

@kevin

Does the Pytrack 2.0X require grounding a certain pin for this to work, or some other workaround?

It does not require it, but it does not hurt. To force bootloader mode, connect P2 aka G23 to GND and then push the reset button. Then the device gets into bootloader mode. Sometimes it is also helpful to reduce the baudrate.