S25FL128S AG unable to erase/programm

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

cross mob
CaRo_4419866
Level 1
Level 1

Hello, I am having an issue with the S25FL128S flash memory, i am unable to programm or erase it at any sector.

I have this part mounted in a custom board to boot a Xilinx Zynq device, and I am unable to perform any erase command (BE, SE, P4E), even with the SDK "program flash" tool, with custom SW with zynq device or accessing through XJTAG programm.

In resume I am able to comunicate with the flash, read it, and write in the internal registers. But when I try to perform an erase or write command, I get an error from the status register read.

I have already check that the footprint is ok, and the 3.3V power supply is over the core supply voltage limit when sending the erase cmd. I have the same issue with the two boards that i have mounted.

Is the flash memory damage or corrupt and i need to change it? Or am I doing something wrong?

I can give a detailed explanation:

- I am able to read properly the ID (cmd 0x9F), the signature (cmd 0xAB), and get back the memory information, this is the log report:

Manufacturer ID = 0x1, Config data byte 2 = 0x20, Config data byte 3 = 0x18
Config data byte 4 = 0x4D
Config data byte 5 = 0x1
Spansion device detected. Checking device id and capacity.
S25 device family.
64 KB sector.
128 Mbit capacity.
All ID values as expected.

Signature = 17
Signature verified.

- I am able to read the status registers and also to write the configuration register, where I disable the the quad SPI operation for XJTAG access (since the driver only has the normal SPI operation). Here I also check that there is no sectors protected, neither is in "write disable" mode, and accepts the write enable command. Here is the log:

Reading flash cfg (0x35)
Cfg reg: 00000010b

Reading some registers...

Reg: 14 value = 00000000b
Reg: 16 value = 00000000b

Reg: 2B value = 0110111111111110b
Reg: A7 value = 00000001b


Writting cfg to disable QSPI

Write enable (0x06)...
Status register :=
  Status register = 0x2

  Status Register Write Disable = 0
  Programming Error Occurred = 0
  Erase Error Occurred = 0
  Block 2 Protection = 0
  Block 1 Protection = 0
  Block 0 Protection = 0
  Write Enable Latch = 1
  Write in Progress = 0


Writting 0x0 to cfg register (0x01)...

Status register :=
  Status register = 0x3

  Status Register Write Disable = 0
  Programming Error Occurred = 0
  Erase Error Occurred = 0
  Block 2 Protection = 0
  Block 1 Protection = 0
  Block 0 Protection = 0
  Write Enable Latch = 1
  Write in Progress = 1
Status register :=
  Status register = 0x3
  Status Register Write Disable = 0
  Programming Error Occurred = 0
  Erase Error Occurred = 0
  Block 2 Protection = 0
  Block 1 Protection = 0
  Block 0 Protection = 0
  Write Enable Latch = 1
  Write in Progress = 1
Status register :=
  Status register = 0x0

  Status Register Write Disable = 0
  Programming Error Occurred = 0
  Erase Error Occurred = 0
  Block 2 Protection = 0
  Block 1 Protection = 0
  Block 0 Protection = 0
  Write Enable Latch = 0
  Write in Progress = 0

Cfg reg = 00000000b

- After this I try to erase the flash, and I have the same result with any erase command (0x20 0x60 and 0xD8) at any address.

Erasing sector at address: 0

Checking block protection....

  Status register = 0x0
  Status Register Write Disable = 0
  Programming Error Occurred = 0
  Erase Error Occurred = 0
  Block 2 Protection = 0
  Block 1 Protection = 0
  Block 0 Protection = 0
  Write Enable Latch = 0
  Write in Progress = 0

Write enable (0x06)...

  Status register = 0x2
  Status Register Write Disable = 0
  Programming Error Occurred = 0
  Erase Error Occurred = 0
  Block 2 Protection = 0
  Block 1 Protection = 0
  Block 0 Protection = 0
  Write Enable Latch = 1
  Write in Progress = 0

SE CMD (0xD8)...
  Status register = 0x23

  Status Register Write Disable = 0
  Programming Error Occurred = 0
  Erase Error Occurred = 1
  Block 2 Protection = 0
  Block 1 Protection = 0
  Block 0 Protection = 0
  Write Enable Latch = 1
  Write in Progress = 1

Flash error
Error erasing

Clearing errors (0x30)
Leyendo status de la flash
  Status register = 0x2
  Status Register Write Disable = 0
  Programming Error Occurred = 0
  Erase Error Occurred = 0
  Block 2 Protection = 0
  Block 1 Protection = 0
  Block 0 Protection = 0
  Write Enable Latch = 1
  Write in Progress = 0

Set SW Reset

- If I skip the erase step, I can read the entire memory to '1', then I try to perform a programm page (PP 0x02) and get the same behaviour (I need to read the status register twice, with the first read the readback is 0x00), here is the log:

Writting page at address: 0

Write enable (0x06)...

  Status register = 0x2
  Status Register Write Disable = 0
  Programming Error Occurred = 0
  Erase Error Occurred = 0
  Block 2 Protection = 0
  Block 1 Protection = 0
  Block 0 Protection = 0
  Write Enable Latch = 1
  Write in Progress = 0


Program "0xAA" pattern to page at address 0(0x02)...
  Status register = 0x0

  Status Register Write Disable = 0
  Programming Error Occurred = 0
  Erase Error Occurred = 0
  Block 2 Protection = 0
  Block 1 Protection = 0
  Block 0 Protection = 0
  Write Enable Latch = 0
  Write in Progress = 0


  Status register = 0x43
  Status Register Write Disable = 0
  Programming Error Occurred = 1
  Erase Error Occurred = 0
  Block 2 Protection = 0
  Block 1 Protection = 0
  Block 0 Protection = 0
  Write Enable Latch = 1
  Write in Progress = 1

0 Likes
1 Solution

Hello Carlos,

I am going to close this case and send you our response via outlook.

Thank you

Regards,

Bushra

View solution in original post

0 Likes
8 Replies
BushraH_91
Moderator
Moderator
Moderator
750 replies posted 50 likes received 250 solutions authored

Hello Carlos,

Thank you for contacting Cypress Community Forum. Can you please check the WP# signal and PPB/DYB protection?

Also please let me know your location.

Thank you

Regards,

Bushra

0 Likes

Thanks for the fast answer.

The WP signal is set to '1' (anyway it should not care if the QSPI is enabled). The solution was the DYB protection, but, i have some questions.

Why the DYB registers are set to '0' protecting all the sectors after POR?

Why are the BP bits in the status register set to '0' if the sectors are protected by the DYB?

If I check all the registers and set it to '1' (if they are '0'), then I can erase and programm the flash. But since the SDK driver does not check this registers it still does not work.

My location is Spain,

Thanks in advance.

Carlos.

0 Likes

Hello,

It looks like the  DYBs are set. The reason might  be one of the following:

  • Boot loader is setting these after power-on
  • Incorrect power-up ramp.

Thank you

Regards,

Bushra

0 Likes

Hello BushraH_91, about your answer,

  • I did not have any boot loader, neither any SW application running that has access to the flash before to try to programm it after the power on, (since I couldn't write the flash memory, the Zynq device can not boot). In addition the bits are volatile, so it can not be configured to start at any value by any "old" SW app before the POR.
  • About the incorrect power-up ramp, I have the Vcc and Vio connected to 3.3V and the CS has a 4K7 pull-up to Vcc also. I check the power up of the board and the 3.3V volts rise in 20ms (green signal). In the datasheet I did not find any ramp specification for the power up.

poweron.ci28.jpg

Could you give me some more information? We need to know if this protection will be active with all the memory parts, since the manufacturer drivers do not work. And also, Why the BP bits in the status register do not show that the memory is protected?

Thanks in advance,

Carlos

0 Likes

Hi Carlos,

the BP status bits we call "legacy protection". It is a different protection mechanism than the DYBs/PPBs which we call "Advanced Sector Protection". There is even more mechanisms such as WP# protection and some devices also have pointer locking. All these are independent and are OR'ed together, i.e. if one mechanism enables protection then the sector is protected, independent of the others.

A normal FL128S should power up with the DYBs unprotected. Just to doublecheck: maybe you can send us the exact laser marking on top of the package (3 lines) or a photo of that. Do all your device behave like this?

Your VCC ramp looks good. In general, all signals shall ramp up smoothly, continuously and steadily. In particular without any glitches are plateaus. Also hardware reset cycles via RESET# shall have this signal go down completely to 0 V and then up again. An incorrect device initialization or reset cycle leads to internally corrupted RAM and can cause all kinds of effect including the one you have observed.

In your earlier email you said you disabled the Quad SPI operation. Does this mean you cleared the QUAD bit so that the device is in single IO mode? In this case, IO2 becomes WP# and IO3 becomes RESET#, and I would suggest to take a closer look at these signals (see if they are floating or have glitches).

Best regards,

Gernot

0 Likes

Hi GernotH_31, thanks for the answer.

Ok, I understand the point about the BP bits in the status register.

I attach the picture of the memory marking (hope the quality is good enough). I only have two prototypes mounted, both of them has the same marking and the same behaviour.

IMG_2907.PNG

Yes I had try to disable the QSPI mode, to access with the XJTAG in single IO mode. And the RESET# pin is pulled up to the 3.3V and I set the WP# to '1' before any access.

Now I have leave the quad mode enabled and I access to the memory with the Zynq. In the board, the WP# signal is pulled down, since the zynq share this signal with the boot_mode strap configuration. But, in quad operation mode it should ignore this pin, isn't it?

Thanks in advance,

Carlos.

0 Likes

Hi Carlos,

thanks a lot for the photo.

Can you send me a direct email?

Cypress uses the standard 1st_name.last_name@cypress.com syntax.

Thanks,

Gernot Hoyler

0 Likes

Hello Carlos,

I am going to close this case and send you our response via outlook.

Thank you

Regards,

Bushra

0 Likes