Using S25FL127S for SPI Flash u-boot

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

cross mob
RyRu_4494066
Level 1
Level 1

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?

0 Likes
10 Replies
Apurva_S
Moderator
Moderator
Moderator
100 likes received 500 replies posted 250 solutions authored

Hi Ryan,

Thank you for contacting Cypress Semiconductor. For better understanding of the problem, I would like to ask you a few questions.

  1. 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?
  2. As mentioned it is a field failure. Are you able to reproduce the failure in the lab? Could you give us screenshots of waveforms?
  3. 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?
  4. 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?
  5. How frequently does your application write and erase to the flash?

Best Regards,

Apurva

0 Likes
lock attach
Attachments are accessible only for community members.

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.

0 Likes

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

0 Likes
lock attach
Attachments are accessible only for community members.

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>

0 Likes

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

0 Likes
lock attach
Attachments are accessible only for community members.

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.

0 Likes
lock attach
Attachments are accessible only for community members.

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.

0 Likes

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.

0 Likes

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.

0 Likes

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

0 Likes