Invalid glasgow_config after flashing a modified firmware

Hi,

I got an assembled Glasgow rev C1 and I am playing with the FX2 firmware. I noticed some strange issues if I erase the FX2 EEPROM, perform a glasgow factory --rev C1:

[ 2080.974006] usb 1-2: New USB device found, idVendor=20b7, idProduct=9db1, bcdDevice= 1.31
[ 2080.974011] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2080.974014] usb 1-2: Product: Glasgow Debug Tool
[ 2080.974017] usb 1-2: Manufacturer: whitequark research
[ 2080.974020] usb 1-2: SerialNumber: C1-20210212T011722Z

And then after a power cycle glasgow flash --firmware firmware/glasgow.ihex with a modified firmware:

[ 2281.649128] usb 1-2: New USB device found, idVendor=04b4, idProduct=8613, bcdDevice= 1.f9
[ 2281.649133] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2281.649136] usb 1-2: Product: Glasgow Debug Tool
[ 2281.649139] usb 1-2: Manufacturer: whitequark research
[ 2281.649141] usb 1-2: SerialNumber: O9-9999999999999999
[ 2286.717811] usb 1-2: can't set config #1, error -110

The board becomes unusable after that and requires a flash erase with an external tool as it is not properly enumerated after a power cycle otherwise:

[ 2624.222003] usb 1-2: new high-speed USB device number 28 using xhci_hcd
[ 2629.374022] usb 1-2: device descriptor read/64, error -110

However, the issue does not appear if I first flash the firmware compiled from master and then the same custom firmware.

My first thought that maybe a memory region grew a bit too much and the memory location of glasgow_config slightly moved and/or was erased by other regions. However it seems to be allocated the very end of the usable memory: https://github.com/GlasgowEmbedded/glasgow/blob/25fe8d326ef2cb01d1316136ec7a86967e90f21b/firmware/glasgow.h#L81

So I tried to slightly increase XRAM and reduce CODE by the same amount: https://github.com/GlasgowEmbedded/glasgow/blob/25fe8d326ef2cb01d1316136ec7a86967e90f21b/firmware/Makefile#L4-L6

None of my attempts solved the issue. Do you have any idea of what kind of black magic could be happening?

[DurandA]

Thank you very much @attie and @electroniceel for the help. I will have a closer look at it in the next few days.

1. It looks like your changes are implementing support for the ATECC chip - if you're using the board from me without modifications, then please be aware that this chip isn't present.

I’m using one of your boards 😉 and yes U34 is unpopulated. I soldered the SOIC variant on the test points at the back.

2. The ATECC chip was removed from future revisions for various reasons, so I _suspect_ that support for it isn't something we're looking for (in case you're aiming at a PR).

I am aware of it. I joined the #glasgow IRC last year to propose my help for authentication and @whitequark told me that the idea was discarded. I proceeded anyway since I am doing some academic work on IoT security and was interested in it.

Thanks for the REC tip, I did not notice it on the board nor in the schematic.

[whitequark]

No. Take a look at the section of the FX2 manual that describes how loads its firmware from EEPROM. In short, there’s a series of length-address-value chunks at the start of the EEPROM, so the EEPROM addresses and the XRAM addresses have no correspondence.