ZYNQ with S25FL512SAG in QSPI mode, random loss of data

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

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hi,

   

I have a design that is lossing data randomly after a power cycle. The design consist of a Zynq using S25FL512SAG dual SS, 4 bit stacked in QSPI boot mode. 

   

There are pull-downs on MIO2, MIO3, MIO4, and MIO6; those pins are connected to the memory. I scope all this signals and all look normal except for MIO4 (W#,DQ2 pin on the memory), see attached image, (Yellow - MIO4/Magenta - Clock).

   

After a review on the forum I read that there is a Pull-Up circuit on WP#, could that be the cause of the unusual behavior on that pin?

   

Could that also be the cause of the random loss of data after power-up?

   

I appreciate any help - pointer on this.

   

Thanks,

   

Diego  

0 Likes
12 Replies
ZhiF_31
Employee
Employee
25 sign-ins 10 solutions authored 5 solutions authored

Hi, 

   

The WP# pin is used for protection. When it is asserted low, the user cannot program or erase any memories. That is why it has an internal pull-up resistor. If the user leaves this pin unconnected, the memory can still be programmed and erased.

   

You will need to make sure WP# pin is high when you try to access to the memory. Some idea with the HOLD# pin. It needs to be high; otherwise, the commands would be ignored.

   

I am not sure what you mean by losing data. Can you elaborate more? Did you see your previously programmed data got erased? or some data were verified to be wrong? 

   

Thanks,

   

Zhi

0 Likes
ZhiF_31
Employee
Employee
25 sign-ins 10 solutions authored 5 solutions authored

Hi Diego,

   

I see your post also mentioned the part is in QSPI mode. If the QUAD bit is set, WP# and HOLD# functions are ignored. So you don't need to have any external pull-ups. I don't think you should add external pull-downs for all the I/O pins.

   

If you can elaborate your issue in more details like I asked in my previous comment, I can help you debug it further.

   

Thanks,

   

Zhi 

0 Likes
Anonymous
Not applicable

Hi Zhi,

   

As I mentioned the system is a Zynq using S25FL512SAG dual SS, 4 bit stacked in QSPI boot mode. The pull-ups/downs are a requirement to configure the boot mode in the Zynq at start-up, (those are boot-strap pins).

   

The problem rise at some point after power cycle, the system get locked looking for the boot image.

   

I really don't know what area of the memory has been corrupted (I'm assuming at least the header of the boot image), in order to recover, I have to load an special .ELF file that bypass the boot from memory and then erase - program the flash.

   

Thanks,

   

Diego

0 Likes
ZhiF_31
Employee
Employee
25 sign-ins 10 solutions authored 5 solutions authored

Hi Diego,

   

Usually the contents of the Flash would not be lost unless the user performs erase or program operations on it. 

   

 

   

Since you mentioned power cycle, you may want to make sure the Flash was not doing any program or erase operations while the power is lost. If that happens, I can see some memories may be corrupted.

   

You may need to do more tests to debug the issue. For example, if you suspect a Flash device losing its contents, you should try to read its memory contents to verify it, even if that means you need to de-solder the part and read it on a separate, maybe stand-alone system. If you compare the master copy with the corrupted copy, you will have ideas how it got corrupted.

   

I understand that requires some efforts, but it may be the only way you can find out why the Flash is corrupted.

   

Thanks,

   

Zhi

0 Likes
Anonymous
Not applicable

Hi Zhi,

   

Ok, I'm preparing a setup and a special driver to compare the memory with the master.

   

As for the image I attached, on DQ2 when it changes from input to output it looks like it's "discharging", is that due to the internal pull-up circuit?

   

Thanks,

   

Diego

0 Likes
TakahiroK_16
Employee
Employee
100 replies posted 50 replies posted 25 solutions authored

Hi Diego

   

 

   

Please see an article in https://www.xilinx.com/support/answers/57744.html

   

This is a known cause of random boot failure in Zynq + QSPI (>=256Mb). Please make sure that your "power cycle" reset the Flash's extended address register.

   

 

   

Best Regards,

   

Takahiro

0 Likes
ZhiF_31
Employee
Employee
25 sign-ins 10 solutions authored 5 solutions authored

Hi Diego,

   

Your image does not show CS# so I am not very sure when the Flash was accessed. I assume the clock toggling periods are when the CS# is low. On the first half, the DQ2 shows floating to low. I think that is related to the external pull-down. On the second half, I see DQ2 is being driven from the device for outputting some data. I think that looks ok. 

   

It seems that if DQ2 is not driven from the device, it floats to low. That means the external pull-down is probably stronger than the internal pull-up resistor.

   

Thanks,

   

Zhi

0 Likes
Anonymous
Not applicable

Hi Zhi,

   

Could that behavior cause random wrong readings?

   

Thanks

   

Diego

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hi,

   

It looks like the problem was at start-up after a power cycle, the part EP53A8HQI outputs 2.5V before being enabled, see attached capture the enable signal is applied at the marker. Before that if supposed to be 0V.

   

Sadly, I couldn't verify whether the extended address register was cleared. (the issue is random and not happen very often).

   

Thanks,

   

 

   

Diego

0 Likes
        Hi Diego, Thanks for sharing the waveform. If the power line is connected to Flash's Vcc, I think the extended address register is cleared because the power is dropped to 0V before ramping up. Is it possible to capture Flash's CS# pin as well as Vcc (capture these two signals at startup)? I would like to check if the POR timing spec is satisfied. Best Regards, Takahiro   
0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hi,

   

the CS# pin has a pull-up resistor to Vcc. so they are roughly the same. The reset pin is not connected. Also HOLD#/DQ3 has a pull-up the other pins (DQ0, DQ1, W#/DQ2, and CLK) have weak pull-downs ~ 20K. 

   

Thanks

   

Diego. 

0 Likes
        Hi Diego, Thanks for the waveform. The POR looks OK. Let's move next steps. As you know the typical boot sequence of Zynq is: 1) BootROM reads BootROM header 2) BootROM reads FSBL image and run FSBL 3) FSBL reads FPGA bitstream (if available) and configure FPGA 4) FSBL reads 2nd boot loader image (typically u-boot) and run it ... We may want to know where the read failure occurs. If you can use UART, defining FSBL_DEBUG_INFO pre-processor symbol can show you detailed FSBL trace. If you can use logic analyzer, you can catch the last Flash read address before the system hangs. Best Regards, Takahiro   
0 Likes