S25FL256S part reads 0x88 not 0xFF with only change batch number. Same software two different results. S25FL256SABF00 831QQ097 A earlier part OK but S25FL256SABF00 851QQ093 A with quad read 0x6B read 0x88 per byte from erased new part (same for several

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

cross mob
tiho_4592101
Level 1
Level 1

We have a board with the S25FFL256S part changed to a newer batch number and are finding the 0x6B quad read command returning 0x88 not 0xFF for the new parts with the exact same software.  This is on all the new boards. This is on a Zynq 7020 for the QSPI flash used for boot.  I am looking into adding dummy cycles (there is one 8 cycle option) but I am worried the silicon is defective now.

S25FL256SABF00 831QQ097 A   Older batch works fine

S25FL256SABF00 851QQ093 A   New batch reads 0x88 not 0xFF for 0x6B quad read with 3 byte address.

0 Likes
1 Solution

Hi,

Can you please confirm that Quad mode has been enabled on the new part? Please try to read Configuration Register 1 and let us know the value of CR1[1] (QUAD) bit.

Regards,

Apurva

View solution in original post

3 Replies
tiho_4592101
Level 1
Level 1

The dummy cycles are already at 8 (L1 and L2 are zero on the configuration register) and reducing to 5Mz clock did not help.  The symptom is actually reading 0x88888888 or sometimes 0x00000000 for the erased part.  The board with this later batch part has some slight power changes so I am now starting to scope the differences between working and non working runs looking at the signals. 

0 Likes

Hi,

Can you please confirm that Quad mode has been enabled on the new part? Please try to read Configuration Register 1 and let us know the value of CR1[1] (QUAD) bit.

Regards,

Apurva

tiho_4592101
Level 1
Level 1

Thank you Apurva. You pointed me at the right thing to look at.  There was a differnece on the Zynq board I omitted and that was the image in flash that worked the Zynq ROM bootloader sets the quad mode bit if there is an image it boots.     So Status: QSPI issue resolved.  The new version processor card does not have any QSPI issue.  Cypress support was quite correct in checking the quad mode bit.  There is no software that sets this in our code or in the Xilinx code but it is required for 0x6B quad fast reads. My initial failure to get the Xilinx programmer to work is unexplained but led me down the wrong path.  Setup code for archives on the device failed.  The read of 0x888888888 for 0xFFFFFFFF was because the QSPI ignored the 0x6B command and no data was driving the 0x8 bit high is IO3 MIO5 which is the boot strap for QSPI boot and the others IO0,IO1,IO2 are all pulled low.  Examination of the configuration value did show in the working case quad mode always set.  But it appears that this is set by the ROM bootloader and only when it can see and load an image.  So I was wrong on several counts: 1) The Xilinx Flash loader worked and knows how to set the quad mode bit.  2) Xilinx driver software in FSBL and provided setup does NOT set the quad mode bit and 3) The ROM boot loader will try and setup for quad reads and sets the quad mode bit. (edited)  Tim

0 Likes