S29GL01GT ready/busy polling not working on -40 degrees

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

cross mob
niluc_3872736
Level 1
Level 1

On the hardware we want to replace the obsolete S29GL01GP11TFIR2 device with the S29GL01GT10TFI020 flash device. Both flash devices are tested with a script running on Linux (version 2.6.29) which continuously erases/writes and verifies the write with read actions. On the S29GL01GP we have seen no issues with the script running for multiple hours (on -40 to +85 degrees Celsius). The S29GL01GT flash device works fine on +25 degrees and +85 degrees Celsius, we experience problems with the ready/busy status readout during the erase command on lower temperatures (-40 degrees Celsius). The ready/busy seems to indicate "ready" but the erase command is not completed. On the hardware we have two S29GL01GT NOR flash devices connected to a local bus which both show the issue.

The Linux driver initiate a sector erase command and waits until the erase is finished by reading the toggle bit status. The Linux driver implementation is according to the data polling sequence illustrated in Figure 7 (S29GL01GT datasheet). When two consecutive reads have the same value the erase status is considered "ready". As a last check the driver reads the first word of the sector (driver used in word mode). When this is not 0xFFFF the last byte is not erased and the driver reports an error (MTD Erase failure: Input/output error). We have tried relaxing the read and write timing settings by adding more delay between read/write cycles, but unfortunately with no success.

Single erase status fail:

Reading the ready/busy status continuously the polling bit value is 0xD508 (third read of the data polling register). The bit toggling has stopped and the erase command should be ready. The S29GL01GT features the status register as another way for getting the FLASH state. If the status register value is read directly after the polling bit value is read the value is: 0x1000 indicating that the erase is not completed. The status register should be 0xXX80, indicating that the flash is done. The ready/busy polling mechanism is not working correctly.

Is the polling mechanism tested on lower temperatures? Is this a known issue with the S29GL01GT10TFI020 Flash device? Are there difference in production revision which could have differences in behavior?

0 Likes
1 Solution
niluc_3872736
Level 1
Level 1

We have done some additional signal integrity measurements. In our measurement setup we attach a debug board to the system which allows connection of a serial debug port, but also creates a stub on the the OEN signal, which causes a reflection right in the middle of the rising and falling edge. As a consequence of this reflection, one read cycle from the processor, generates two toggles on the S29GL01GT, and therefore software concludes too early that the erase/program cycle is complete. On boards with the S29GL01GP this was never observed as it is probably a bit slower. So the problem was not with the part, but in the board design. We have taken appropriate measures, which solved the problem. Thank you for your support!

View solution in original post

0 Likes
10 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. We will get back to you as soon as we find the resolution.

Thank you

Regards,

Bushra

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

Hi,

I would like to ask some questions about your test.

1) How many sectors are participated in the test?

2) How many erase/write cycles were performed before seeing this symptom?

3) How many sectors show this symptom?

4) By using status register read instead of polling, the erase eventually completes or timed out?

Thanks,

Takahiro

0 Likes

Hello,

We are waiting for your answer to the question sent on Jan 30, 2019.

Thank you

Regards,

Bushra

0 Likes

Hi,

1) How many sectors are participated in the test?

- Chip 1: All sectors participate in the test (except the first three containing boot information).

- Chip 2: 48 sectors participate in the test.

2) How many erase/write cycles were performed before seeing this symptom?

- Both Flash devices where new and soldered on the PCB before starting the test. The DUT is tested with the script for 24 hours on 25 and 80 degrees Celsius before the -40 degrees test. The amount can only be estimated, it is the order of a maximum of 1000 erase/write cycles per sector.

3) How many sectors show this symptom?

- Chip 1:The sector is erased, written (with different values) and checked 4 times. We have tested the script on almost all sectors. Randomly in one of the four erase cycles the symptom occurs for almost all sectors. If the script is run again and the sector is retested, the polling mechanism could work fine the first time and fail the second time. This is also the other way around.
- Chip 2: Partially tested, polling issue failures are less frequent than Chip 1. It was some calculation to get the full amount of sectors: 48 sectors participate in the test which are tested 28 times.Tested 48 x 4 x 28 =5376 times. The script failed 5 times. Again it is completely random when the issue occurs, if the sector is retested the polling mechanism could work fine the first time and fail the second time.

4) By using status register read instead of polling, the erase eventually completes or timed out?

- To read the status register the flash driver should be modified. As experiment we have updated the driver to read the status register after the polling register states that the flash is done. The status register indicates that the chip is still busy and eventually returns to ready. Updating the driver as a fix is unwanted, we want to reuse the R/B polling mechanism as is the current driver.

0 Likes

Hello,

We are still looking into the issue.

Thank you

Regards,

Bushra

0 Likes

Hello,

Can you please provide us the failure rate?

Are the failures isolated to a single date code?

Thank you

Regards,

Bushra

0 Likes

Hello,

We have replaced the Flash devices on another DUT for the S29GL01GT10TFI020. The issue described above is now tested and observed on two DUT's, there are 2 Flash devices per DUT (4 Flash devices in total). We will gathering the information regarding the date code of these flash devices.

Greetings, Nick

0 Likes

Hello,

Thank you for the update. I have forwarded the information to PE. They looking into the issue based on the information your provided. Please bear with us.

Have a wonderful day

Regards,

Bushra

0 Likes

Hello,

There are multiple ways of reading the status of the device (RD/BY, DQ Polling, Status register) with different levels of information feedback from the device. Would it be possible for you to use DQ Polling and / or status register only and not combine with RD/BY? Do you still see the failure at -40C if either DQ Polling or Status Register reads are used? Please let us know.

Thank you

Regards,

Bushra

0 Likes
niluc_3872736
Level 1
Level 1

We have done some additional signal integrity measurements. In our measurement setup we attach a debug board to the system which allows connection of a serial debug port, but also creates a stub on the the OEN signal, which causes a reflection right in the middle of the rising and falling edge. As a consequence of this reflection, one read cycle from the processor, generates two toggles on the S29GL01GT, and therefore software concludes too early that the erase/program cycle is complete. On boards with the S29GL01GP this was never observed as it is probably a bit slower. So the problem was not with the part, but in the board design. We have taken appropriate measures, which solved the problem. Thank you for your support!

0 Likes