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.
1 of 1 people found this helpful
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 (QUAD) bit.
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