Stm32h7 Hal qspi autpolling timeout

[JCuna.1]

I am writing a library for a flash memory. At the beginning I am trying to reset the flash memory. So in order to avoid a bad reset. I am checking if wip is enable. However, the flash memory could be in spi or qpi mode. So I am trying to perform and autopoll status read in both case.

After hours of debugging I realize that when Hal qspi autopolling method reach timeout, it is locked and I can not use again. Even Hal qspi abort unlock the device. Checking the qspi peripheral, busy bit is set. So I perform a peripheral reset and init again the peripheral with MX qspi init.

​

After this, autopolling method works again but it only perform a additional read and then reach timeout (my timeout is 1000ms). So it is pretty strange because this only perform and autopoll status reg once, and in one second this should perform many reads.​

[Tesla DeLorean]

Do some simple queries of status registers or JEDEC ID to establish your ability to read, and the mode of current operation. Frequently specific commands which can always be in one-bit mode, and others which will respond differently depending on mode, and address widths, etc.

[JUhlí.1]

Hello,

I am having an issue with autopolling too. I tried a lot of combinations of modes (1/4 Instruction lines, 1/4 Address lines, 1/4 Data lines). For me it seems there is a problem at least with (4-4-4) mode with autopolling. It looks it works fine in (1-1-1) mode or (1-4-4) mode. I connected it to analyzer and the results are quite strange.

[Tesla DeLorean]

@Community member​ had some other posts. I think we pinged ST, and got crickets..

I recall looking at the library source for the HAL QSPI, it has an odd exit path for the TIMEOUT, and you need to do an HAL_QSPI_Abort() type operation to terminate it at a bus level. None of the examples do anything to handle this properly in my opinion. This might change in time and with attention..

The exact implementation depends on STM32, QUADSPI or OCTOSPI, and library version, but the timeout is a software based one, whereas the hardware continues in this mode. You can check the instance status, but if still BUSY it's going to preclude further operation. You need to Abort the hardware operation to get back to an operational state. Similarly Abort can be use to exit memory mapped mode, rather than resetting and tearing every down which ST is apt to do in examples, and loaders, etc.

Editing a bit for clarity, and as forum migration lost some contextual detail.

[JUhlí.1]

Thank you for response. Later yesterday I saw other @Community member​ posts and your reactions. I think that waiting for timeout and then calling abort will be in result slower than using (1-1-1) for polling (which is working fine)

[Tesla DeLorean]

@ChahinezC​ marking for review