STM32H753 QSPI Status Flag Polling fails with Instruction on 4 lines

[regjoe]

Hello,

I stumbled across a probably already wellknown problem:

unable-to-use-quadspi-status-flag-polling-mode-with-instruction 

Now I'd like to know if there are any news, somebody wrote that the issue is observed by ST.

Second I'd like to know if newer H75x revisions or devices with OCTO/HEXASPI (H735, H7RS, N6, ) suffer from the same problem(s).

Third, regarding the comment from TeslaDeLorean, I'd like to know if this behaviour is related to the flash device.

Ok, the problem:

If I use 4 lines for instructions for status register polling of a QPI-able flash (MX66L1G45) I observed that if the WIP bit is set in the first status poll, the polling cycle is done, but the next polling fails.

If the WIP is reset at the first time it is polled, the pollings stops, the program continues.

That caused a race condition on my side (works, works not, works, ...) and took some time to investigate...

Here is the situation: first poll is OK (2 clocks for command request, 2 clocks for status reply). WIP bit is set, so the status polling continues. But the second poll halts after the 3rd clock, and the NCS is kept in active state. Looks like the internal logic of the H7 QSPI locked up.

So at first look, it seems this is a H7 problem, but regarding the first successful poll, this timing is also weird:

After the first two clocks, driven by H7, the next 2 clocks are driven by the flash, here SIO0 (blue) and SIO1 (red). What puzzles me is the extra puls after the NCS is inactive. Who drives the SIO0 output at that moment? Telling from the signal height and reflections, it seems that the H7 is the source of it.

Also, as far as I know, (Q)SPI data is shifted at falling clock edge and sampled at rising edge. This seems to be true for the first 2 clocks and for the forth clock. But regarding the 3rd clock, things are different.

In my understanding, the flash should drive its first bit at the falling edge of the 2nd clock. Indeed, after that, the voltage is a bit lower compared to the H7 output before. But then, in the middle of the rising edge of the 3rd clock, the SIO0 (blue) changes from 1->0, exactly when the H7 is sampling the data. In my opinion, what the H7 reads here is unsure, maybe 0 or 1.

So, is this a bug in the flash or in the H7? Does this extra pulse cause the following H7 lockup? Is there any workaround?

Thank you.

 

 

 

 

 

 

 

[Tesla DeLorean]

Well, a lot of moving parts here.

The IC and STM32 need to be in agreement about what mode they are in, and the template for the command needs to be cleared and fully populated, auto/local variables aren't implicitly clear and contain random stack junk unlike global statics.

Different IC's need 4-pin operation selected independently of QPI mode (ie sending 4-bit commands/data), the default modes depend on factory settings, and part suffixes. Seen issues with some Winbond W25 having issues with IO2/#WP expectations.

Some Micron parts have dummy cycle expectations, and the multi-die parts cycle through the die as CS# cycle, so when we want to check if it's BUSY/READY you have to read FLAGS 4 times to an array and get a vote on it. One die can be actively writing or erasing, whilst the others have completed. Just sending one command gets you the next die in the cycle randomly.

The Auto-Poll on STM32 side is problematic because it just keeps hammering, ie it drops CS# sends the command, and then just loops cycling data on the defined interval, clocking out a new status, and doesn't release CS# until it gets a match, or you abort. The Timeout paths on some HAL variants fail to Abort, and the peripheral keeps hammering. You can see this is failure to dispatch subsequent commands. This might have been addressed since I complained about it, but it's a potential bear-trap to consider. I moved to a process of sending individual commands to create my own faux auto-polling method.

The MX66 are the multi-die Macronix parts, sorry don't have a lot of personal experience with them, but think they're are less odd than Micron.

Also on the Winbond's in can cycle between SR1 and SR2 on the READ STATUS, so a 16-bit value for mask and comparison.

@ChahinezC @STTwo-32 

[Tesla DeLorean]

>>So, is this a bug in the flash or in the H7? Does this extra pulse cause the following H7 lockup? Is there any workaround?

Work around would be to not use Auto Polling, code the process of reading and checking flags with individual command/read methods, so CS# cycles.

Make sure exit paths Abort the QSPI. Check in case of timeout, perhaps flag a GPIO as you exit, and can see the timeout on the logic analyzer.

Check the Errata, but ST evolves the peripherals as it creates new parts, they generally don't fix/respin the die in subsequent steppings. They might address other issues, but generally the significant IP doesn't change. So this issue likely to remain in H74x and H75x die into the future.

Different models, see DEV_ID, might have better IP

[regjoe]

Looks like the H7 QUAD peripheral needs at least one dummy cycle if data is read in QPI mode (RM0433 Rev 8 chapter 23.3.3):

In order to assure enough “turn-around” time for changing data signals from output mode to
input mode, there must be at least one dummy cycle when using dual or quad mode to
receive data from the flash memory.

If zero dummy cycles are configured, which is a valid value for the peripheral, strange things happen as reported above.

The workaround, as suggested by the ST support, is to configure 2 dummy cycles for the flash status register read operation. Although the flash has no option to configure dummy cycles for this command, it does work in this special case, because the flash repeats the data every two additional clock cycle sent by the H7.

The sceenshot below shows that the data (WIP bit set) is sent twice, once during the dummy cycles and once in the data read phase.

  

I'm not sure this will work for other flash register read commands, ... IMHO, this unexpected behaviour is a candidate for the errata sheet, but ST thinks that the note in the RM is sufficient. Well,...