-
Notifications
You must be signed in to change notification settings - Fork 188
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.
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
Invalid revision value after flashing EEPROM #186
Comments
You can use |
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 For some reasons, I always have to call |
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. |
That's really strange actually. Please do this: After step (2), read the EEPROM with |
All dumps are identical after (2), (4), (6) and (8). Edit: |
All dumps are identical after (2), (4), (6) and (8). I did the process several times and please ignore my previous edit. |
That's really weird. I'll have to use one of my devkits to reproduce. |
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? |
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. |
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. |
This was also my first hypothesis but I wondered if this was a jelly-bean part that is massively counterfeited like the FTDI chips.
That could very well be the case given that the board + shipping was cheaper than the CY7C68013A in > 1k quantitites.
Yes, I have a FX2-based logic analyzer. 😆 I will try that tomorrow. Many thanks for your time. |
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. |
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. |
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). 😕 |
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. |
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
. Usingglasgow -vv factory --rev C1
produces the following output:However,
lsusb | grep 20b7:9db1
showsBus 001 Device 047: ID 20b7:9db1 Qi Hardware
. If I proceed withglasgow -vv flash
anyway it produces the following output: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
The text was updated successfully, but these errors were encountered: