- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We ran into an obsolescence issue on our product. Previously we were using Micron part N25Q128A13ESE40G but now we're using Cypress part S25FL127S. Our processor loaded up fine and it seemed like a perfect drop-in replacement but after several weeks in the field we are experiencing a high number of failures that we've traced back to the S25FL127S. We haven't yet been able to determine if the part is breaking or if it is being corrupted.
Doing some research I notice that Cypress has its own SPI Flash U-boot patch. Since all of our design for this product was done by a 3rd party vendor I'm not sure if any u-boot changes were made when we switch parts. Could this cause the flash to have a delayed failure?
- Labels:
-
Part Number Query
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ryan,
Thank you for contacting Cypress Semiconductor. For better understanding of the problem, I would like to ask you a few questions.
- Could you please let us know how did you confirm that the failure is being caused by the flash? What is failing in the flash? Can you please give us more details about the failure?
- As mentioned it is a field failure. Are you able to reproduce the failure in the lab? Could you give us screenshots of waveforms?
- Here is the link for the u-boot patch for Cypress SPI flash devices - https://www.cypress.com/documentation/software-and-drivers/u-boot-patch-spi-flash. Could you please confirm and let us know if u-boot changes were made while migrating from Micron part to Cypress Flash?
- What do you mean by breaking? Does it mean physical damage to the device? What is the physical condition in which the flash is being used?
- How frequently does your application write and erase to the flash?
Best Regards,
Apurva
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for your resposne,
1. So we are using a ADSP-BF609BBCZ-5 blackfin processor for our product. Upon boot-up we read from the the SPI flash. We were eventually able to find out that our U-boot wasn't functioning correctly which led us to the Cypress SPI Flash chip. Reprogramming the chip didn't fix the issue but when we replaced the chip with a brand new part with the same manufacturing date code we were able to reprogram the board and it functions correctly.
2. So far we are unable to reproduce failure. We took one of the failed boards, replaced only the Cypress Flash, and have tried to make the board fail again. We have been power cycling the product every 3 minutes to allow it to fully boot up. We've been running this for over a week and haven't seen a failure. I can work to get useful plots of the signal. Currently we're getting noise if there is any length of wire between the probe's ground and the board's ground.
3. I was able to determine that we did not make any changes to the u-boot when we switched to the Cypress Flash. This is what we're currently investigating as the potential cause.
4. So far we are unable to tell if the flash is broken or corrupt. What we do know is that sometimes we are unable to reprogram the flash and other times we reprogram the flash but the error is still there.
5. As far as I am aware we only erase/write to the flash when we first manufacture the board. Whenever the board powers on we read from the flash and the chip remains unused until it is power cycled. In the field the product is power-cycled roughly 20 times a day.
Attached is the schematic of how the flash is being used. All of the signals that go off the page go directly to the processor.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ryan,
Thank you for providing the information.
I would like to add questions/requests:
1) What is the u-boot version do you use?
2) Could you please send the source files of "/drivers/mtd" ?
3) What stage is your system failing at? "sf probe" to read Flash device ID or "sf read" to load kernel, or other?
4) You wrote "...we are unable to reprogram the flash", what's the u-boot message at that time?
5) Is it possible to send u-boot terminal logs?
Thanks,
Takahiro
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
1) We're Currently using "U-Boot 2015.07 ADI-2014R1-pre (Oct 25 2018 - 12:00:23 -0700)". We noticed the patch is for uboot 2013, is this patch something we need to still consider?
2) See Attached
3) Some of the boards previously failed at the sf probe command but we were unable to reproduce this. The other boards failures are captured in the following console output.
4) So it appears I was misinformed. Reprogramming of the chip appears to succeed but when we try to boot up again we see the output below.
5) See Below.
U-Boot 2015.07 ADI-2014R1-pre (Oct 25 2018 - 12:00:23 -0700)
CPU: ADSP bf609-0.0 (Detected Rev: 0.0) (spi flash boot)
Clock: VCO: 500 MHz, Core: 500 MHz, System0: 125 MHz, System1: 125 MHz, Dclk: 250 MHz
Watchdog enabled
I2C: ready
DRAM: 128 MiB
Flash: 64 MiB
MMC: Blackfin SDH: 0
SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB, total 16 MiB
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
other init
initcall sequence 07f80880 failed at call 07f425ac (err=1)
KGDB: [on serial] ready
Net: dwmac.ffc20000
Warning: dwmac.ffc20000 (eth0) using random MAC address - 86:0d:e8:d9:bd:8a
Hit any key to stop autoboot: 0
0000
SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB, total 16 MiB
device 0 offset 0x80000, size 0x300000
SF: 3145728 bytes @ 0x80000 Read: OK
0000
Wrong Image Format for bootm command
ERROR: can't get kernel image!
bfin>
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Thank you for the information.
1) I don't think you need to apply our patch. The u-boot 2015.07 should work without patching.
5) Since you get "Wrong Image Format for bootm command", at least the header part of the kernel image is corrupted. I would like to see how the image is corrupted. Just after you get the ERROR: can't get kernel image!, the image read from the Flash is still in DRAM. Could you dump the image in DRAM by "md" command and compared it with the expected kernel image?
Thanks,
Takahiro
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Attached are the kernel images. The file named uImage_ADU was dumped from the broken flash chip while the other file is our expected file. It seems that there is a byte off between the files but a visual inspection of the files from our software people says they seem to be identical.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for the images.
As you mentioned, the "sf read" misses the first byte of the data.
A potential cause of this is that the read latency setting in the Flash configuration register is accidentally changed.
I would ask you to instrument a debug code into drivers/mtd/spi/sf_probe.c to print configuration register value.
The attached file contains the debug code at line#350 ~ 354, for reference.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
This is the output after adding that debug code.
U-Boot 2015.07 ADI-2014R1-pre-svn1759 (Oct 08 2019 - 10:51:34 -0400)
CPU: ADSP bf609-0.0 (Detected Rev: 0.0) (spi flash boot)
Clock: VCO: 500 MHz, Core: 500 MHz, System0: 125 MHz, System1: 125 MHz, Dclk: 250 MHz
Watchdog enabled
I2C: ready
DRAM: 128 MiB
Flash: 64 MiB
MMC: Blackfin SDH: 0
config: C0
SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB, total 16 MiB
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
other init
initcall sequence 07f808b4 failed at call 07f425ac (err=1)
KGDB: [on serial] ready
Net: dwmac.ffc20000
Warning: dwmac.ffc20000 (eth0) using random MAC address - 02:09:ec:d5:89:ed
Hit any key to stop autoboot: 0
0000
config: C0
SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB, total 16 MiB
device 0 offset 0x80000, size 0x300000
SF: 3145728 bytes @ 0x80000 Read: OK
0000
Wrong Image Format for bootm command
ERROR: can't get kernel image!
bfin> md.b $(loadaddr) 10
01000000: 05 19 56 68 d5 7d 0f 5b d2 17 06 00 25 a6 42 00 ..Vh.}.[....%.B.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As far as this goes, would it be possible to organize a conference call or have a direct contact to discuss this issue assuming you are Cypress employees?
So far all of the information provide has been useful and we would like to keep the flow of information consistent.
Thank you for all of the help you've given us so far and any potential future help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Sorry for the message spam. The following log is from a functional Cypress part:
U-Boot 2015.07 ADI-2014R1-pre-svn1759 (Oct 08 2019 - 10:51:34 -0400)
CPU: ADSP bf609-0.0 (Detected Rev: 0.0) (spi flash boot)
Clock: VCO: 500 MHz, Core: 500 MHz, System0: 125 MHz, System1: 125 MHz, Dclk: 250 MHz
Watchdog enabled
I2C: ready
DRAM: 128 MiB
Flash: 64 MiB
MMC: Blackfin SDH: 0
config: 00
SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB, total 16 MiB
In: serial
Out: serial
Err: serial
other init
initcall sequence 07f808b4 failed at call 07f425ac (err=1)
KGDB: [on serial] ready
Net: dwmac.ffc20000
Warning: dwmac.ffc20000 (eth0) using random MAC address - de:ba:63:06:ce:9b
Hit any key to stop autoboot: 0
bfin> sf probe 1
config: 00
SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB, total 16 MiB