-
Hi everyone,
I am tinkering with a Cypress FX2LP clone and I don't really understand the EEPROM jumper.
Unfortunately I can't tell the manufacturer as nothing is printed on the pcb...
I have two different boards which have a different behavior for the EEPROM activation Jumper.
On one board the connected jumper connects A0 of the EEPROM to high and without the jumper it is connected internaly to GND to not float.
On the other board it seems to be connected to low via the jumper and pulled to high without the jumper.
So at least one of them is like the LCSoft Board https://www.coreboot.org/images/6/60/Fx2lp_lcsoft_schematic_A.pdf
The problem I'm trying to get my head around: it is always said that the jumper activates/deactivates the EEPROM but when a0 is either connected to 3,3V or GND because when the pin is floating it is internaly connected to GND (EEPROM Atmel AT24C128). So the write address is always 0xA0 or 0xA2.
So how is it then deactivated?
Is it because of this information from the datasheet?Code: [Select]I2C Port Pinshttps://www.infineon.com/dgdl/Infineon-CY7C68013A_CY7C68014A_CY7C68015A_CY7C68016A_EZ-USB_FX2LP_USB_Microcontroller_High-Speed_USB_Peripheral_Controller-DataSheet-v31_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ec9f7974252
The I2 C pins SCL and SDA must have external 2.2-k pull-up
resistors even if no EEPROM is connected to the FX2LP.
External EEPROM device address pins must be configured
properly. See Table 8 for configuring the device address pins.
Table 8. Strap Boot EEPROM Address Lines to These Values
Bytes Example EEPROM A2 A1 A0
16 24LC00[13] N/A N/A N/A
128 24LC01 0 0 0
256 24LC02 0 0 0
4K 24LC32 0 0 1
8K 24LC64 0 0 1
16K 24LC128 0 0 1
Does it mean that the EEPROM is only recognized at boot time when A0 is high ?
Another question in regard of the addressing:
In different tutorials/forums it is always written that the A0 pin changes the address to either 0xA0 or 0xA2 but this is the address to write to because of the LSB beeing for the direction, isn't it?
So the address is not "selected" by the jumper to be either 0xA0 or 0XA2 but depends on the operation and can also be 0xA1 or 0xA3 when it should be a read operation.
Edit: link fixed -
The EEPROM jumper on the FX2LP clone board helps configure the device address of the EEPROM, allowing it to be accessed correctly on the I2C bus. The jumper does not activate or deactivate the EEPROM but rather sets the appropriate address configuration.
-
FX2LP will always access a fixed address A0=1, A1=0, A2=0. The jumper to 3.3V needs to be set for the EEPROM access to work and you remove it to get an unprogrammed device. If the jumper is removed, FX2LP would still try to read, will fail and go into the default mode.
The direction bit is not a part of the address. When using 8-bit address values, people usually talk about just the high 7-bits, LSB is always assumed to be 0 in the address. -
Thank you both for the explanation.
What happens now when at boot time another EEPROM is connected to the FX2LP at 0xA0 ?
Now it gets complicated:
I modified VID/PID in the EEPROM on 0xA2 which is read during the boot sequence and my PC reconizes it as the device for which I modified the IDs.
When another EEPROM (holding no valid VID/PID so no C0 or C2 mode triggered) is connected the VID/PID from the FX2LP "internal storage" is used, not the one from the EEPROM.
Just like no EEPROm was found at all.
I built this tool https://www.hexefx.com/diy/utility/fv1prog to access the EEPROM of another device that is tied to 0xA0 to write some DSP code to the second EEPROM.
There it is stated that the FX2LP searches at boot time for an EEPROM on 0xA0 and 0xA2. That's the reason why there is a daughter board that connects the second EEPROM on the external device on 0xA0 by controling a 4066 IC via an interrupt IE0 (SUDAV).
FX2LP --> read VID/PID from onboard EEPROM 0xA2
|
connect after boot sequence via 4066
|
v
external device with EEPROM on 0xA0
So far it works perfectly as intended. But when I keep in mind that the FX2LP only looks at 0xA2 as it is mentioned in the datasheet and was confirmed here then why is it a problem when during boot time a second EEPROM is connected to 0xA0 ?
I jumpered the SCL/SDA relevant pins on the 4066 to have the second EEPROM directly connected without the 4066 in between to verify the problem.
Don't get me wrong, I don't want to bother anyone neither you nor the guy who came up with the idea to isolate the second EEPROM during boot time but I want to understand why it is like that.
Edit: I also connected the second EEPROM on a breadboard to the FX2LP not only via the external device to avoid multiple masters but it is the same issue.
-
Ok, the fixed address was not entirely correct. It was to describe the way it works on those evaluation boards and why there is a jumper. If you said from the beginning that there was another EEPROM involved, the answer would have been different.
It does try two addresses - 0xa0 and 0xa2 to determine what size of the EEPROM is connected. Size of the EEPROM defines how many bytes are used for the internal address, so it is important to know for following access. So, if you have another EEPROM on either of those addresses, it may be used instead.
If you want FX2LP to not boot from any EEPROM, there must be no EEPROMs on either address. And no I2C devices in general, since the way it knows that there is a device is by an ACK for the address byte. Any device responding at that address would be assumed to be an EEPROM.
The solution is to place that other EEPROM at any other address. -
Ah ok. That‘s what I found a few minutes ago which makes sense then as you described it exactly like this. From the EZ-Usb Dev Kit ManualQuote
The EZ-USB loader determines the EEPROM size by first initiating an I 2 C transfer to address 1010000 (1010 is the EEPROM class address, and 000 is the sub-address). If the device supplies
So the 4066 is necessary to remove the second EEPROM during boot time.
an I 2 C acknowledge pulse, the EZ-USB loader writes a single EEPROM address byte to initialize the internal EEPROM address pointer to zero.
If the above transfer does not return an ACK pulse, the EZ-USB loader initiates a second I 2 C transfer, this time to address 10100001 (1010=EEPROM, sub-address 001). If an ACK is returned
by the I 2 C-device, the EZ-USB loader writes two EEPROM address bytes to initialize the internal EEPROM address pointer to 0.
If neither transfer returns an ACK pulse, the EZ-USB loader boots in ‘generic’ mode (explained below). -
It is still strange, if you are adding external control circuit anyway, it would be easier to just control A2 of the external EEPROM, for example. Just pull it up by default and set it to 0 from the GPIO after FX2LP boots.
-
The FX2LP should act as a Spin Semi Dev Board a programmer for devices (in my case guitar pedals) that contain a Spin FV-1 DSP and an EEPROM holding the DSP code.
The EEPROM inside the FV-1 Device must be tied to 0xA0. There is no information about this in the datasheet of the Spin FV-1 or the Dev Board but it is written on some web sites and all the pedals that have been built around this chip use 0xA0 for the EEPROM. I guess I should use my logic analyzer to find out :-)
I used the logic analyser on the FX2LP to raise some more questions when the external EEPROM is directly connected to the FX2LP (no 4066 IC in use) or not conected at all:
The first column is what I expected. No Ack for 0xA1 as there is no external EEPROM and the onboard EEPROM containing the VID/PID/DID is read from 0xA3. The FX2LP is enumerated as SPIN Dev Board.
The second column is what I did not expect. The external EEPROM is tied to 0xA0 there should be an Ack, shouldn't it?
Or is there no Ack because there is no C0 that can be read from that EEPROM? Or are the C0 or C2 modes independent of the discovery of a i2c device?
The third and Fourth column is expected because now there is an address conflict, both EEPROM are on 0xA0. There is no VID/PID/DID found in both EEPROM because of this conflict and the FX2LP uses the hardcoded IDs. Or did it unfortunately read the external EEPROM first which does not contain any ID?
-
There is some contradiction here in the column 2. If there is indeed EEPROM on 0xA0, then why did it not ACK the 0xA1 read? ACK does not depend on the contents, it just means that there is some device at that address. If it did not ACK, then there is no EEPROM at that address.
The third and fourth columns are wrong because it detected a device with 1 byte internal address, but the actual EEPROM has 2 byte internal address. It only writes one byte and starts the read, which returns 0xff, since address was incomplete, and stops the transfer.
-
Thanks for your feedback!
I gave it another try but it seems that the breadboard test is not as satisfying as with the EEPROM in the external device.
Column 1 and 2 are the readings for the EEPROM on the breadboard. This time the EEPROM on 0xA0 is recognized but not read. Maybe the wires are too long?
Column 3 is the external EEPROM directly in the guitar pedal on 0xA0 and the output matches what is stored in the EEPROM.
Column 4 are both EEPROM on the same address 0xA0 (also external EEPROM in the guitar pedal). I marked red the difference to the content of the external EEPROM.
Column 5 is only the internal EEPROM and it's content which is correct. I moved the fields down so they can be compared to column 4 because I thought that column 4 is maybe a mix of both EEPROM.
-
I am not sure if this adapter for Eeprom can help you, but you can try to have it, works pretty good for me, easy read and write the eeprom or flash memories in-circuit
https://www.3ello.com/home -
Thanks Franco. I have adapters for accessing EEPROM, I was just trying to understand the FX2LP and why it behaves like it does :-)
-
You can't connect EEPROM with2-byte internal address (size > 256 bytes) to the address 0xa0.
You don't get to pick which address you want to use. You have to use 0xA0 if you have 24LC00/24LC01/24LC02. and you have to use 0xa2 if you have any other EEPROM. Any other configuration is not going to work. -
Then just for my understanding it's not what I intend to do:
I did not pick the addresses for the whole thing to work but I tied them to see what happens to understand the outcome.
So even if the 24C32 on 0xA0 is correctly read in column 3 (visible on the logic analyzer) it would not work for example as a source for VID/PID on 0xA0 (right now it's DSP code no VID/PID) because its size is > 265 bytes.
And column 3 is messed up because both are tied to 0xA0 which is just not possible.
-
I don't understand what is even happening in column 3. The first byte of the EEPROM must be either 0xC0 or 0xC2 to indicate VID/PID load or a complete firmware load. The first byte it reads in the big chunk is 0x80. I don't even know why it proceeds after that. But even before that happens, the behavior is very strange. It may not be a clean capture or something like that.
If you use 2-byte address EEPROM and only supply one byte before the read, you are relying on the rest of the address being reset to 0 after the first byte write. And this is not something that is guaranteed by EEPROM manufacturers. You will be essentially reading from random addresses, not 0. This is not functional for either VID/PIV nor firmware mode because you simply can't get any data reliably out.
The other way around might actually work. Using small size EEPROM, but configuring FX2LP to treat it as large one.
-
0x80 and everything after that is the correct content, the DSP code stored in the EEPROM of the external device.
But for now thanks a lot for the insights.
I will use the FX2LP with the daughter board that adds the external EEPROM after the boot and everything is fine.