Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Invalid revision value after flashing EEPROM #186

Closed
DurandA opened this issue Feb 20, 2020 · 17 comments
Closed

Invalid revision value after flashing EEPROM #186

DurandA opened this issue Feb 20, 2020 · 17 comments
Labels
question Meta: question / support issue

Comments

@DurandA
Copy link

DurandA commented Feb 20, 2020 •
edited

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):

glasgow/firmware/adc.c

Line 40 in bd9625c

PORTACFG |= _INT0;

@whitequark
Copy link
Member

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

@whitequark whitequark added the question Meta: question / support issue label Feb 20, 2020
@DurandA
Copy link
Author

DurandA commented Feb 27, 2020

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
Copy link
Member

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
Copy link
Author

DurandA commented Feb 27, 2020

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

  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
Copy link
Member

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
Copy link
Author

DurandA commented Feb 27, 2020 •
edited

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
Copy link
Author

DurandA commented Feb 27, 2020

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

@whitequark
Copy link
Member

whitequark commented Feb 27, 2020 •
edited

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

@DurandA
Copy link
Author

DurandA commented Feb 27, 2020

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
Copy link
Member

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
Copy link
Member

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
Copy link
Author

DurandA commented Feb 27, 2020

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. 😆 I will try that tomorrow.

Many thanks for your time.

@DurandA
Copy link
Author

DurandA commented Feb 28, 2020

Here is the trace:

image

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
Copy link
Member

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
Copy link
Member

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
Copy link
Author

DurandA commented Feb 29, 2020

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

@DurandA
Copy link
Author

DurandA commented Feb 29, 2020 •
edited

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.

@DurandA DurandA closed this as completed Feb 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question Meta: question / support issue
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@whitequark @electroniceel @DurandA