STM32H7 Quad SPI broken bit when output is switching to input with NOR flash

[SLesh.1]

Hi there!

I have a problem when using QSPI with NOR flash. Some read commands return data with first 4 bits corrupted.

After investigation, I have found that the issue only appears if there is switch from output to input without dummy cycles.

For example (see picture): I send a 4-line, 1 byte instruction (2 cycles) and read 4-line 3 bytes (6 cycles). I expect IO2 (blue) to switch from output to input prior to clock's (yellow) third falling edge. Instead, it seems to be held at some grey level, that is sometimes sampled as 1 at the third rising edge.

 

Same issue was observed on STM32H7 with 2 different flash chips, using quad-spi and dual-spi.

Yellow is clock, blue is IO2

I can’t find something similar in errata.

Are some ideas, guys?

[Mike_ST]

Hello

What QSPI reference are you using ?

QSPI might need dummy cycles to work as expected, this should be written in the datasheet of the flash.

[SLesh.1]

I'm using Winbond W25Q32JV and ISSI IS25LP032D

f.e. https://www.issi.com/WW/pdf/25LP-WP032D.pdf page 75 - according the document JEDEC ID should be read without dummy cycles.

[Mike_ST]

In page 76 figure 8.55 in QPI mode you need 8 clock cycles before reading the ID.

Page 75: 8.31 "The RDMDID

instruction code is followed by two dummy bytes and one byte address (A7~A0), "

But from what I understand you are expecting incoming data after 3 clock cycles.

[SLesh.1]

I'm using 0x9F command - page 75 (not 76), figure 8.30. No dummy cycles demand in this case.

[Tesla DeLorean]

If it's in 1-bit mode why is the state of IO2 changing?

The state of IO1 would be more interesting, as would the clock edge you're sampling on. Tv is on the order of 7-8 ns

In QPI mode the QUADSPI peripheral may have a turn-around time also, I haven't dug into the specs.

[Mike_ST]

Ok, I watched wrong command.

So I guess you're seding 0xAF not 0x9F for quad mode.

[Andreas Bolsch]

W25Q32JV doesn't support 4-4-4 mode at all, so it's out of consideration, and 0x9F only in 1-1-1 mode accourding to 8.1.2 and 8.1.3.

Unfortunately the picture is rather bad (Your scope has USB and LAN, so most likely you could provide a screenshot?). What's the timebase? Keep in mind that most quad-capable flash chips allow only a rather slow clock for most commands, and the prominently advertised high clock rates only for a very limited set of commands like quad read, but *NOT* for the read id command. That's one reason why dummy clocks are necessary for the high speed reads. Some devices even don't support the 0x9F read id at all in 4-4-4 mode.

[Ilya Balov]

Hi! On behalf of SLesh.1 I will try to provide any further required information.

No, we are using 0x9F, which works in both 1-line and qpi modes. I tried 0xAF and observed the same issue.

[Ilya Balov]

Sorry for poor quality picture, we will try to provide a better one.

For W25Q32JV there is no 4-4-4 mode indeed, but we see the same behaviour with a different command:

0xBB - Fast Read Dual I/O (https://www.winbond.com/resource-files/W25Q32JV%20RevI%2005042021%20Plus.pdf, page 31).

The issue is observed if last 2 bits of alternate bytes (M7-0) are set to 1 (for example, when we send 0xFF).

We tried to scale down the clock by 20x times, with no improvement. The clock on the picture is below 5 MHz. You can see that for entire duration of the third down clock, blue signal is held at around 1 V, which seems to be the root cause.