- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Labels:
-
Parallel NOR
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.