S29VS256R MirrorBit Flash Unable to Enter CFI Mode

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

cross mob
JoZe_2473996
Level 1
Level 1
First like given Welcome!

We have a design that uses the S29VS256RABBHI010 MirrorBit flash chip, that occasionally (~0.1% of the time) fails to boot.  The bootloader code is U-boot, and it indicates that it cannot recognize the flash.  We've troubleshot this to the point where we attempt to issue the commands to enter CFI mode (reset, followed by ID/CFI Entry), and the flash appears to remain in read mode, and does not transition to CFI mode.  If we follow the reset/CFI entry commands with CFI reads to address offsets 0x20, 0x22, and 0x24, we do not see the "QRY" string that we expect.  These are the same commands that U-boot is using, and this only happens about 0.1% of the time, or less.  We can get the flash to respond in CFI mode if we issue a board level reset signal (which also resets the flash).

Has anyone experienced this before, or know why the flash chip might fail to enter CFI mode?

Thank you.

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

Hi,

Thank you for contacting Cypress Community.

  • Can you please provide us the uboot code/log messages?
  • You have mentioned that the device starts to respond after a reset. Can you also provide us the reset timings?

Regards,

Apurva

0 Likes

The testing that we're doing involves all warm resets over 100ms long.

The uboot log message is "Flash: ## Unknown flash on Bank 1 - Size = 0x00000000 = 0 MB"

Here's a snippet of uboot code where this comes from:

/* Init: no FLASHes known */

for (i = 0; i < CONFIG_SYS_MAX_FLASH_BANKS; ++i) {

    flash_info.flash_id = FLASH_UNKNOWN;

    /* Optionally write flash configuration register */

    cfi_flash_set_config_reg(cfi_flash_bank_addr(i), cfi_flash_config_reg(i));

    if (!flash_detect_legacy(cfi_flash_bank_addr(i), i))

        flash_get_size(cfi_flash_bank_addr(i), i);

        size += flash_info.size;

        if (flash_info.flash_id == FLASH_UNKNOWN) {

            printf ("## Unknown flash on Bank %d - Size = 0x%08lx = %ld MB\n",i+1, flash_info.size,flash_info.size >> 20);

        }

...

When we had it in the failed state, we used a BDI2000 to issue these commands, which is what uboot does:

mmh 0x08000000 0x00f0 1

mmh 0x08000000 0x00ff 1

mmh 0x080000aa 0x0098 1

mdh 0x08000020 1

mdh 0x08000022 1

mdh 0x08000024 1

The mdh commands respond with 0x01A0, 0x0800, 0x0200, which is the data stored in flash.  After resetting the board from this state, these same commands respond with 0x0051, 0x0052, 0x0059, which is the ASCII string "QRY", as expected in CFI mode

0 Likes

The flash is currently in the state where it will not enter CFI mode.  I have a BDI2000 attached to the processor, so I can issue individual memory read and write commands.  When I issue the reset (write 0xF0 to flash offset 0x0000), followed by CFI entry (0x98 to flash offset 0x00AA), and then try to read offsets 0x20, 0x22, and 0x24, I do not get the "QRY" ASCII string.  Please let me know what commands I can issue to further debug this.

0 Likes

Hi,

We have a few questions about your previous response -

mmh 0x08000000 0x00f0 1

mmh 0x08000000 0x00ff 1

mmh 0x080000aa 0x0098 1

1) For the 2nd command, why did you send the 0xFF command to flash? VS-R doesn't support FFh reset command, only 0xF0 command is supported.

2) For the ID/CFI entry, have you also tried 0x90 command?

Regards,

Apurva

0 Likes

Those writes are mimicking what uboot does.  Since uboot does not know what flash is installed, it does both the AMD and Intel style resets.  I've tried to repeat the commands without the 0xFF, as well as with 0x90 for ID/CFI entry, but I get the same result... the flash does not enter CFI mode.

0 Likes

Hi,

  • Could you please let us know  if it only happens on the same part or it happened on more than one parts?
  • Is it possible for you to capture the waveform with logic analyzer for the G and NG parts for CFI enter and read operations?

Regards,

Apurva

0 Likes

Multiple parts have exhibited the problem across different boards and at slightly different rates.  It typically takes a couple of thousand power or reset cycles for the flash to get into this state, but once it's in this state, it will never respond to the CFI entry command.  However, data reads work just fine (we haven't tried writes).

Unfortunately, too many of the signals a buried in the PCB for me to be able to probe a meaningful number of signals to get any good timing information.  However, I do not suspect that timing is a problem, due to the fact that (1) reads work just fine, and (2) once the flash gets into a state of not responding to CFI commands, it remains in that state until it gets reset.  If there were a timing issue, according to our reboot cycle counts, it would happen less than 0.1% of the time, which we don't see when the flash gets into this "stuck" state, where 100% of CFI commands fail.  Also, if there were a timing issue on the interface on any signal other than WE, then the reads would have problems, which they do not.

We also don't believe it has to do with powerup, as the problem exists even with just reset cycles, where power is not removed.  I'm currently investigating the reset signal.  Is there any condition of the deassertion of reset that could cause the flash CFI circuitry to get into a state where it refused to respond, but where data reads would operate normally?

0 Likes

Hi,

Apologies for the late response.

We suspected the timing reason but since you have mentioned the normal read worked fine, Could you please let us know the batch or date code of the device?

Thank you and Regards,

Apurva

0 Likes

I guess it's my turn to apologize for the late response :-).

The date code is 612BB778.

Also, I had been doing some extended testing over the past several weeks (which made it difficult to get the board to a microscope to read the date code).  There are 2 flash chips on the board that is being tested, and each flash chip is connected to a processor (and each of the 2 processors are the same).  On this particular board, we've only seen the issue on "processor 1" where "flash 1" would fail to enter CFI mode when requested.  We've never seen a case where "processor 2" was unable to get  "flash 2" into CFI mode.  There is a single common reset signal that goes to both processors and both flash chips.  The reset signal is driven by an open drain driver with a nominal 10%-90% rising edge (exponential RC decay) of about 900ns.

I had changed my testing to drive the reset signal from an arbitrary waveform generator to create a linear rising edge on the reset of varying 10%-90% times. In one case, I used a faster rising edge at about 70ns.  This did not fail on over 60,000 reset cycles for either processor.  The worst case so far is a 300µs rising edge, which produced failures on both processors.  This is the first time we were able to get "processor 2" to fail to get "flash 2" into CFI mode.  I tried an even longer rising edge (1.3ms), but that only produced failures on "processor 1" / "flash 1"... "processor 2" and "flash 2" behaved just fine.  Both flash chips have the same date code, by the way.

The datasheet does not indicate any requirements for the rise (or fall) time for the RESET# input.  Is there an undocumented requirement for this?

Could a slow rising edge on the RESET# input cause this issue?

Do you have any experience with parts exhibiting this behavior in response to a slow RESET# input?

0 Likes