Invalid revision value after flashing EEPROM

[DurandA]

Hi,

After a few flashes, I can't revert the EEPROM to factory firmware anymore.

I don't have a Glasgow yet so I am using a FX2LP dev board (EZ-USB FX2LP CY7C68013A—schematic outdated on the link, I can't find one for the newer revision) to play with the firmware without the iCE40 connected.

After resetting the FX2LP, the host detects it as Bus 001 Device 046: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit . Using glasgow -vv factory --rev C1 produces the following output:

D: g.device.hardware: loading firmware from /home/duranda/devel/glasgow-vanilla/software/glasgow/glasgow.ihex
D: g.device.hardware: loading firmware to revC1 device
E: g.cli: device not found

However, lsusb | grep 20b7:9db1 shows Bus 001 Device 047: ID 20b7:9db1 Qi Hardware. If I proceed with glasgow -vv flash anyway it produces the following output:

Traceback (most recent call last):
  File "/home/duranda/devel/glasgow-vanilla/venv/bin/glasgow", line 11, in <module>
    load_entry_point('glasgow', 'console_scripts', 'glasgow')()
  File "/home/duranda/devel/glasgow-vanilla/software/glasgow/cli.py", line 796, in main
    exit(loop.run_until_complete(_main()))
  File "/usr/lib/python3.8/asyncio/base_events.py", line 612, in run_until_complete
    return future.result()
  File "/home/duranda/devel/glasgow-vanilla/software/glasgow/cli.py", line 436, in _main
    device = GlasgowHardwareDevice(args.serial, firmware_filename)
  File "/home/duranda/devel/glasgow-vanilla/software/glasgow/device/hardware.py", line 73, in __init__
    revision = GlasgowConfig.decode_revision(device_id & 0xFF)
  File "/home/duranda/devel/glasgow-vanilla/software/glasgow/device/config.py", line 59, in decode_revision
    raise ValueError("invalid revision value {:#04x}".format(value))
ValueError: invalid revision value 0xaa

I was able to flash the firmware previously, so I guess I corrupted the EEPROM at some point. I am using the same CAT24C256W as on the schematic with pin 1 tied to VCC and pin 2 left floating.

Do you have any advice on how I could flash EEPROM? I don't have spare EEPROM but I can erase it with an Arduino if required. I am using the vanilla master branch with the below line commented to prevent interrupts from triggering (as advised by @whitequark): https://github.com/GlasgowEmbedded/glasgow/blob/bd9625cdf85c8dad3911ca1b38cc3604ee0cf5a2/firmware/adc.c#L40

[whitequark]

You can use fx2tool -d xxxx:yyyy -B write_eeprom ... with any FX2 based device. It's in the libfx2 Python package.

[DurandA]

fxtool is excellent, thanks! The only related tool I found is fxload and doesn't seem to be practical to write EEPROM. For reference, I used dd if=/dev/zero ibs=1k count=256 | tr "\000" "\377" > paddedFile.bin to pad with 0xFF and then fx2tool -d 04b4:8613 -B write_eeprom -f paddedFile.bin.

For some reasons, I always have to call glasgow factory to boot from the EEPROM after a reset/power cycle. I had a look at EZ-USB FX1/FX2LP Boot Options but couldn't figure why it doesn't boot directly to the EEPROM. Do you have any suggestion?

[whitequark]

For some reasons, I always have to call glasgow factory to boot from the EEPROM after a reset/power cycle.

Can you describe the steps you are taking exactly, starting from some known state? The boot process is a bit subtle so I can't tell just from your description here.

[DurandA]

Starting with empty EEPROM (filled with 0xFF) connected to the FX2LP dev board as follow:

1. At this point, lsusb shows ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit.
2. glasgow factory --rev C1.
3. lsusb still shows ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit.
4. Reset.
5. lsusb still shows ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit.
6. glasgow factory --rev C1.
7. lsusb shows ID 20b7:9db1 Qi Hardware.
8. Reset.
9. lsusb shows ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit.

[whitequark]

That's really strange actually. Please do this: After step (2), read the EEPROM with fx2tool. After step (4), (6) and (8) do it again. Compare the result, or just post the dumps here.

[DurandA]

All dumps are identical after (2), (4), (6) and (8).

Edit: ~I'm doing the process again and it seems that there are some changes.~

[DurandA]

All dumps are identical after (2), (4), (6) and (8). I did the process several times and please ignore my previous edit.

[whitequark]

That's really weird. I'll have to use one of my devkits to reproduce.

[DurandA]

I bought the cheapest board available on AliExpress. Do you know if there are fake FX2 chips around? Could it be a FX2 disguised as FX2LP?

[whitequark]

Seems super unlikely. What I think is more likely is that you don't have other peripherals real Glasgow boards do, and that trips up the boot process somehow.

[electroniceel]

It could be a genuine FX2LP that was recycled and damaged in the process. There are some backyard recycling gigs in China that remove valuable ICs with big blowtorches and similar methods.

Do you have a logic analyzer? If yes, maybe take a look at the I2C bus and check if the FX2 is successfully reading from your EEPROM directly after reset.

[DurandA]

What I think is more likely is that you don't have other peripherals real Glasgow boards do, and that trips up the boot process somehow.

This was also my first hypothesis but I wondered if this was a jelly-bean part that is massively counterfeited like the FTDI chips.

It could be a genuine FX2LP that was recycled and damaged in the process. There are some backyard recycling gigs in China that remove valuable ICs with big blowtorches and similar methods.

That could very well be the case given that the board + shipping was cheaper than the CY7C68013A in > 1k quantitites.

Do you have a logic analyzer?

Yes, I have a FX2-based logic analyzer. :laughing: I will try that tomorrow.

Many thanks for your time.

[DurandA]

Here is the trace:

I think that the EEPROM replies with 0xFF at address 0 instead of 0xC0. This is really strange since it reads C0 at address 0 when I dump the flash using fx2tool.

[electroniceel]

Is there another EEPROM on the I2C bus?

A0 of the Glasgow EEPROM is high, A1 and A2 low (001). The FX2 tries to read from 000 first and some EEPROM seems to answer there, so the FX2 acts on that answer and does not do the C0-boot we want.

[whitequark]

Is there another EEPROM on the I2C bus?

There almost certainly is, the FX2 devboards come with a EEPROM that @DurandA needs to disconnect for things to start working. Sometimes there's a jumper on SCL or one of the address pins.

[DurandA]

Is there another EEPROM on the I2C bus?

No, I unsoldered the EEPROM that came with the FX2 devboard. And I re-checked the connection of the EEPROM, A0 is connected to VCC (measured 3.3V with my multimeter). :confused:

[DurandA]

I mixed up the CAT24M01 and the CAT24C256. The CAT24M01 doesn't have A0 so the address was 0x50...

I am really sorry for your wasted time.

@electroniceel I just realized you were the author of the awesome SMD protoboard. I really love it, I have to try the new variant with ground plane.