S29GL01GS Flash problem with erasing the first sector

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

cross mob
frgo_4197001
Level 1
Level 1

Last year we switched to using the Cypress S29GL01GS10FHI02 Flash. We are currently having a problem on all these systems with erasing sector zero with our custom MTD driver running on a PPC 440EP. All other sectors erase and program fine using that driver. Sector zero can be erased and programed under U-boot. If U-boot is used to boot the system, then our custom MTD driver can erase and program sector 0 correctly.

When it fails to erase, the flash reports a status of A2 after ~10us, which according to document #001-98285 Rev R means Erase failure because sector is locked. However, the sector is not locked. It can be programmed with U-boot and the MTD driver in the same way after a U-boot boot. Also, reading the lock state (both volatile or not) of that sector returns 1 (Unprotected). Trying to unprotect the sector has no effect. The memory map appears to be correct as I can read the sector correctly from the MTD driver and all commands issued to the flash at that base address work (except the erase of sector zero). The bus speed is the same under U-boot or the factory boot (125ns). Nothing in the documentation hints at sector zero being special. The code to erase is very simple; the Sector address = base address in this case.

#define AMD_CMD_ERASE_START                                      0x0080

#define AMD_CMD_ERASE_SECTOR                                   0x0030

#define AMD_CMD_UNLOCK_START                                   0x00AA

#define AMD_CMD_UNLOCK_ACK                                       0x0055

#define AMD_ADDR_START                                                  0x0555

#define AMD_ADDR_ACK                                                       0x02AA

volatile u_short* base = (u_short*)( s->vaddr );

volatile u_short* addr = flash_make_addr (s, blkno);

              *(base + AMD_ADDR_START ) = AMD_CMD_UNLOCK_START;

              SYNC;

              *( base + AMD_ADDR_ACK ) = AMD_CMD_UNLOCK_ACK;

              SYNC;

              *(base + AMD_ADDR_START ) = AMD_CMD_ERASE_START;

              SYNC;

              *(base + AMD_ADDR_START ) = AMD_CMD_UNLOCK_START;

              SYNC;

              *( base + AMD_ADDR_ACK ) = AMD_CMD_UNLOCK_ACK;

              SYNC;

              *( addr ) = AMD_CMD_ERASE_SECTOR;

              SYNC;

Please help,

Frederic

0 Likes
1 Solution

I found it. The normal BL drives the VP# signal whereas U-boot doesn’t!

Your manual explains the behavior I was seeing and somehow I missed it:

3.4.1 Write Protect Signal

If WP# = VIL, the lowest or highest address sector is protected from program or erase operations independent of any other ASP configuration. Whether it is the lowest or highest sector depends on the device ordering option (model) selected. If WP# = VIH, the lowest or highest address sector is not protected by the WP# signal but it may be protected by other aspects of ASP configuration. WP# has an internal pull-up; when unconnected, WP# is at VIH.

View solution in original post

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

Hello,

Thank you for contacting Cypress Community Forum. Currently we are reviewing the issue and we will get back to you as soon as we find the resolution.

Have a wonderful day

Regards,

Bushra

0 Likes

Hi Frederic,

is this under Linux? If so, what kernel version are you using?

And do you have partitions defined? Can you send us the full boot log?

Some other details you might check: is the power-on ramp OK, i.e. is VCC ramping up steadily without glitches?

Do you have logic analyzer access? How does a u-boot erase differ from a Linux erase on the bus?

Do you have traces when you checked the DYB and PPB of sector 0?

Best regards,

Gernot

0 Likes

Hi Gernot,

Thank you for your reply.

The system runs a custom RTOS. The Flash are only used during boot to load the kernel image and are updated infrequently when we make patches to those images. As far as I can tell there is no difference between the U-boot interface and the runtime MTD driver. Both work fine when booted using U-boot. The problem appears to be with the normal boot-loader, which is a strip down version of U-boot. The BL sets up the peripheral bus, reads the flash (including sector zero), and launches the kernel image that was on it. Once the OS is running (it doesn't matter how long) you can chose to update the kernel image on the Flash. This can be done for any images that do not include sector zero. However, for the image that starts at sector zero the erase fails. It works fine for the previous Flash chips we were using.

The boards do not have an easy way to attach a Logic Analyzer. Both the CPU and the Flash are BGA chips so we cannot attach wires to the pins. There are some resistors on the bus we can use, but I was hoping to avoid it if possible. Hence my inquiry here.

It seems odd that every other sector works flawlessly and sector zero is always broken. The Flash works or doesn't in a predictable manner. I don't know what the BL could be doing (or not doing) to make that happen.

0 Likes

Hi Frederic,

there is multiple potential causes for this. The simplest one is that the sector 0 is really locked.

When you checked the DYB and PPB bit, did you do a little bit more tests around that, e.g. setting these bits and re-reading? Just to make sure your DYB/PPB entry and exit commands are correct.

Other causes might be:

- a bug in the implementation of flash_make_addr ();

- the device is still in another ASO,

- incorrect Power-Up

- timing or controller issue (a logic analyzer would identify that)

BR, Gernot

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

I added debug outputs in the driver to see what is put on the bus by the CPU. The address bus is 16-bit, but lane zero is not connected, so all commands are shifted by one bit. The outputs are done after a command sequence (ASO entry/exit) to avoid interfering with timing.

I recorded a failed attempt and a successful attempt by the same driver/OS on the same sector (attached). They only differ in how the OS was booted.

Thanks for your help.

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

I tried your suggestion of locking and then unlocking the sector, but it still fails with a normal boot and works after a U-boot boot. In both cases I try to erase the sector after locking it. It fails with the expected A2 code, then I clear the lock bits (wait) and try to erase again. When booted with U-boot it works, but otherwise it still fails as if the sector was locked. I’ve attached the output of both runs.

At this point I’m sure the sector isn’t really locked. This leaves the incorrect power up and bad timing cases.

During a normal boot we test the hardware watchdog by having it reset the board. This occurs after power is on for at least 100ms and the reset line is held low for 60ms. Is that a problem?

Here’s a trace of the 3.3V and reset lines after power up.

0 Likes

Can you disable that extra reset (via watchdog) for testing purposes?

Another thing that came up my mind: GL-S does not support "unlock bypass mode" as earlier devices did. It can have strange effects when enabled, so you might check that your normal boot loader is not using that.

Best regards, Gernot

0 Likes

In the waveform I see that RESET# does not go completely down to 0 V during that extra cycle, which is not good.

Regarding POR, we should also take a much more detailed look at the VCC ramp.

0 Likes

No luck. Removing the extra reset had no effect.

We can measure it, but if VCC ramp was an issue it would affect both boot method equally.

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

Here’s the VCC ramp.

It looks like we need to wire up the Logic Analyzer (this will take a while).

Let me know if you think of anything else in the meantime.

Normally the BL or the driver do not lock any sectors. The chips come unlocked. I do not know what the “bypass mode” is, but we do not use it. In fact, the BL and driver did not have any lock/unlock capability until I added the code for troubleshooting.

Thanks,

Frederic

0 Likes

I found it. The normal BL drives the VP# signal whereas U-boot doesn’t!

Your manual explains the behavior I was seeing and somehow I missed it:

3.4.1 Write Protect Signal

If WP# = VIL, the lowest or highest address sector is protected from program or erase operations independent of any other ASP configuration. Whether it is the lowest or highest sector depends on the device ordering option (model) selected. If WP# = VIH, the lowest or highest address sector is not protected by the WP# signal but it may be protected by other aspects of ASP configuration. WP# has an internal pull-up; when unconnected, WP# is at VIH.

0 Likes

Well, this is a little bit exotic put also possible. Good that you found the cause 🙂

And good that it is documented here now so that other can search and find it quickly.

Thanks, Gernot

0 Likes