CY15B104Q-SXI Data Read Corruption After WRITE of ALL Locations with 0xAA

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
tacq
Level 1
Level 1
5 sign-ins First reply posted First question asked

We have seen the following situtation when using a CY15B104Q-SXI which is accessed by an FPGA on a board with stable power up timing. After a an operation which writes ALL of the locations with a three (3) pass method with 0x00, 0xFF, and 0xAA (the FRAM will be left with ALL locations at 0xAA) we have found errors in the data read from the FRAM. It appears that the data read out by the FPGA from the device into a Block RAM buffer inside the FPGA is incorrect. We have the actual device in hand. Also, during debug of our code it was possible that WRITE accesses ocurred at a location past 524,287 (rollover).

Here are some details of the operation :
The power up code sets the WRDI to have BP(1:0) set to "00" : No Write protection

The WRITE operations are all performed with a WREN command and then a block WRITE with the entire memory length written in one block. There are no individual WREN WRITE operations at a single address. The FRAM is written with one WREN/WRITE of the entire 512K size with same data witten in three passes : 0x00, 0xFF, and last 0xAA.

The READ operations which _export_the_entire_memory_to_a_host_PC_over_a_UART port from the FPGA are individual READ operations at a single address and the output looks correct.

The READ operations which _load_a_portion_of_the_FRAM memory to the BRAM inside the FPGA are block READ operations from an offset address to a small range of less than 16K Bytes. When we export the contents of the BRAM (loaded from FRAM) we see corruption in the form of the AA bytes occupying a large section of the expeted data, followed by the remainder of the expected data. THe BRAM is loaded with the fast read option.

Now, we have shown that when we BLOCK WRITE using the three (3) method (again, all are BLOCK WRITEs of exact length of the full FRAM size starting from addr 0 and ending at 524,287) with write timing obeyed (CS high duration between Block Write operations at 25MHz SPI timing) gives incorrect READ data from the BRAM buffer to the host. We can see that some swaths (contiguous regions) still have incorrct data in them from a previous pass.

However, we have found out that when we change the operation of the FRAM three pass to finish with 0x00 (00's left in entire FRAM space) the READ operations are performed correctly for all locations.

0 Likes
1 Solution
Ritwick_S
Moderator
Moderator
Moderator
100 solutions authored 25 likes received 250 sign-ins

Hi @tacq,

 

Since the READ operations which _export_the_entire_memory_to_a_host_PC_over_a_UART port from the FPGA is successful, it seems like there is no problem with our FRAM. There might be some issues on the BRAM side because of which corruption is observed.


> The power-up code sets the WRDI to have BP(1:0) set to "00": No Write protection
- I would like to correct you here. WRDI command clears the WEL bit in the Status Register, which disables any write to the memory. For changing the BP0 and BP1 values, you need to first send the WRSR command and then write the status register. So, WRDI has nothing to do with BP0 and BP1.


> The BRAM is loaded with the fast read-option
- Are you sending a dummy byte after a 19-bit address? This needs to be done for the fast read operation. Also, could you please try loading BRAM with normal read operation and let us know the result?


> When we change the operation of the FRAM three pass to finish with 0x00 (00's left in the entire FRAM space), the READ operations are performed correctly for all locations.
- Could you please try sending just 0xFF or just 0xAA and let us know the result? Are the READ operations performed correctly for all locations? Also, this case is the same as above, i.e., you are reading from FRAM, then writing into BRAM, and then reading the BRAM, correct?


Thanks,
Ritwick

 

View solution in original post

0 Likes
3 Replies
Ritwick_S
Moderator
Moderator
Moderator
100 solutions authored 25 likes received 250 sign-ins

Hi @tacq,

 

Since the READ operations which _export_the_entire_memory_to_a_host_PC_over_a_UART port from the FPGA is successful, it seems like there is no problem with our FRAM. There might be some issues on the BRAM side because of which corruption is observed.


> The power-up code sets the WRDI to have BP(1:0) set to "00": No Write protection
- I would like to correct you here. WRDI command clears the WEL bit in the Status Register, which disables any write to the memory. For changing the BP0 and BP1 values, you need to first send the WRSR command and then write the status register. So, WRDI has nothing to do with BP0 and BP1.


> The BRAM is loaded with the fast read-option
- Are you sending a dummy byte after a 19-bit address? This needs to be done for the fast read operation. Also, could you please try loading BRAM with normal read operation and let us know the result?


> When we change the operation of the FRAM three pass to finish with 0x00 (00's left in the entire FRAM space), the READ operations are performed correctly for all locations.
- Could you please try sending just 0xFF or just 0xAA and let us know the result? Are the READ operations performed correctly for all locations? Also, this case is the same as above, i.e., you are reading from FRAM, then writing into BRAM, and then reading the BRAM, correct?


Thanks,
Ritwick

 

0 Likes
tacq
Level 1
Level 1
5 sign-ins First reply posted First question asked

> The power-up code sets the WRDI to have BP(1:0) set to "00": No Write protection
- I would like to correct you here. WRDI command clears the WEL bit in the Status Register, which disables any write to the memory. For changing the BP0 and BP1 values, you need to first send the WRSR command and then write the status register. So, WRDI has nothing to do with BP0 and BP1.

You are correct, I issue the WRSR command at power up to define the BP[1:0] bits to "00" (no protection)

 

> The BRAM is loaded with the fast read-option
- Are you sending a dummy byte after a 19-bit address? This needs to be done for the fast read operation. Also, could you please try loading BRAM with normal read operation and let us know the result?

I was incorrect about about the use of the Fast Read option. In fact, I am using the READ timing in Figure 12 of the data sheet. I have attached the detailed timing


> When we change the operation of the FRAM three pass to finish with 0x00 (00's left in the entire FRAM space), the READ operations are performed correctly for all locations.
- Could you please try sending just 0xFF or just 0xAA and let us know the result? Are the READ operations performed correctly for all locations? Also, this case is the same as above, i.e., you are reading from FRAM, then writing into BRAM, and then reading the BRAM, correct?

>>> The READs from FRAM to_Load_BRAM are the block type READ shown in the timing diagram I have attached. 

The READs from FRAM to_EXPORT_FRAM to UART are the Single Byte Access READs also from Figure 12 of the datasheet (A single byte address is requested and /CS is de-asserted after that single byte Read from the FRAM. All of the data read from the FRAM to Export over UART to Host PC is done in this way.

 

0 Likes
tacq
Level 1
Level 1
5 sign-ins First reply posted First question asked

Could you please try sending just 0xFF or just 0xAA and let us know the result? Are the READ operations performed correctly for all locations? Also, this case is the same as above, i.e., you are reading from FRAM, then writing into BRAM, and then reading the BRAM, correct?

After power up After Writes, then the block Reads are used to fill the BRAM. When we want to Export the FRAM contents to the host PC over UART we Read the indvidual byte locations one READ operation at a time. 

I think we can what you have suggested.

0 Likes