- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Solved! Go to Solution.
- Tags:
- sector erase command
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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