S29GL01GS read issue in linux

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

cross mob
jakw_4183911
Level 1
Level 1

Hi all,

We got some trouble in linux(3.14.39 or 4.14.53) with S29GL01GS11TFIV10. Using command "hexdump -n 10 /dev/mtdblock0", we got incorrect data from S29GL01GS after linux bringing up (mtdblock0 is at NOR FLASH offset 0). Logic analyzer show that the address is correct but data is not. No file system mount, erase,program operated in the NOR FLASH during linux bring up. But hexdump again, correct data is got. Everything is working functionally except this issue. We tried a micron NOR FLASH, everything is ok.

0 Likes
8 Replies
GernotH_31
Employee
Employee
First like received

How many data bits are wrong? Are these just single bits that are flipping or entire data blocks?

In order to analyse this further, we would suggest to look at the following aspects:

- bus timing, are all signals within the spec?

- power-on timing; are there any glitches on VCC during power-on? Is VCC ramping up steadily and smoothly?

Finally, instable data can be caused by interrupted program operations. This means, if power drops during a write/program operation then the data afterwards will be wrong and instable (due to partially programmed flash cells). Can this be excluded?

Thx, Gernot

0 Likes

Hi Gernot,

Thanks for reply.

Not single bit wrong. The wrong data had no obvious pattern, but read again the data is correct.

We check the timing, nothing suspicious is found. By the way, u-boot, linux kernel, rootfs and other firmware are stored in the NOR FLASH, all of them running functionanlly. We think that the data in the NOR FLASH is correct and the interrupted program operations may be excluded. It seems that the read operation to the NOR FLASH is OK at most of the time, only the first one after linux bringup is wrong.

0 Likes

Can you attach a hex dump of the first bytes, 1) when the data is wrong, and 2) when the data is correct?

Is the wrong data always the same?

Thx, Gernot

0 Likes

Hi Gernot,

The hex dump showed below, the correct data is aa 55 aa 55 ... And the wrong data is NOT always the same.

[root@LSDK ~]# hexdump -C -n 10 /dev/mtdblock0

00000000  ff ee ee ff fe ef ee fe  ff ee                    |..........|

0000000a

[root@LSDK ~]# hexdump -C -n 10 /dev/mtdblock0

00000000  aa 55 aa 55 01 ee 01 00  08 10                    |.U.U......|

0000000a

[root@LSDK ~]# hexdump -C -n 10 /dev/mtdblock0

00000000  aa 55 aa 55 01 ee 01 00  08 10                    |.U.U......|

0000000a

/*****************************     After cold reset ******************************/

[root@LSDK ~]# hexdump -C -n 10 /dev/mtdblock0

00000000  ff ee ee ff ff cf 83 b8  ff fe                    |..........|

0000000a

[root@LSDK ~]# hexdump -C -n 10 /dev/mtdblock0

00000000  aa 55 aa 55 01 ee 01 00  08 10                    |.U.U......|

0000000a

[root@LSDK ~]# hexdump -C -n 10 /dev/mtdblock0

00000000  aa 55 aa 55 01 ee 01 00  08 10                    |.U.U......|

0000000a

0 Likes

Thanks for the quick response. It looks like the first read gives some kind of random data. I am wondering if the device outputs (drives) this data on the bus? You said that you attached a logic analyzer and verified it. Are there traces available of these erroneous reads?

Also, does this happen just immediately after Linux start-up? I.e. what if you do first an erase or program operation to another location first? Are the reads then correct from the first time on?

Thx, Gernot

0 Likes

Hi Gernot,

Yes, the device outputs (drives) this wrong data on the bus. But the traces are not saved.

If do an erase and program operation first, the reads are correct.

Btw the read operation is correct in U-boot. And there are some CFI/ID reads during the linux bringup, is there any chance the flash still in ASO or other states after linux bringup?

0 Likes

If the device is still in another ASO mode, then the data would be consistent, i.e. always the same.

Are these older samples? What is the date code of the parts (2nd line of the laser marking on the package)? And would it be an acceptable workaround for you to add some extra dummy operations as a kind of special initialization to the chip driver (cfi_cmdset_0002.c)?

Best regards, Gernot

0 Likes

Hi Gernot,

Sorry for my late reply. Here are the laser marks:

SPANSION

S29GL01GS11TFIV1

711BB742 C

(c)10 SPANSION

Workaround is acceptable and we also want to know the root cause.

0 Likes