QSPI flag 'QSPI_FLAG_BUSY' sometimes stays set

[Peter Olsson]

Posted on October 30, 2017 at 08:47

Hello,

We'rehaving an issue on STM32F765IGT - when trying to use flash on QSPI, configured in 'Indirect mode', using HAL v1.8.0, and DMA enabled.

It's quite hard to replicate, but it seems to occur whenthere are lots of DMA and interrupts going on. The result is that QSPI_FLAG_BUSY stays set, and it stays that way forever.

As a workaround I've used the following code, right before sending HAL_QSPI_Command(). Before executing this, I check my internal state to make sure that QSPI is in fact not busy. In 'stm32f7xx_hal_qspi.c' I've found some ifdef'sfor 'QSPI_V1_0', which kind of gave me the idea to use the abort command like this. However, it was not possible to just enable the compiler directive, since we must also make sure to set 'State' to 'HAL_QSPI_STATE_BUSY', or the abort function won't do anything at all.

if ((FlagStatus)(__HAL_QSPI_GET_FLAG(&qspiHandle, QSPI_FLAG_BUSY)) == SET)
{
 qspiHandle.State = HAL_QSPI_STATE_BUSY;
 HAL_QSPI_Abort(&qspiHandle);
}�?�?�?�?�?

Has anyone else seen any similar issues?

Regards,

Peter Olsson

#stm32f7-hal #quadspi #qspi

[Daniel Blanchard]

Posted on November 20, 2017 at 09:40

Hello, Peter.

We also encounter the same kind of problem with an STM32F756NG (without DMA).

Under unknown circumstances, we notice that the 'BUSY' flag becomes active again. In our case :

- Reading of the Quad Spi flash in indirect mode : All goes right, the BUSY flag is cleared at the end of the reading (In addition, an ABORT is requested at the end of the read).

 - Some time later, the software wants to make an other access to the Quad Spi flash... but the BUSY flag is set again ?

Right now, we implemented the same workaround than you did : Addition of an ABORT before any request (even if there is already an ABORT after all requests).

Syncerly yours,

Daniel Blanchard

[Amel NASRI]

Posted on November 20, 2017 at 14:07

 Hi peter.olsson‌ & Daniel.Blanchard‌,

Here you are reporting 'the same' problem' for 2 different products.

I would like to get more details on both configurations. Would it be possible for you to share the code you are using, that may help to reproduce the issue, even if it is not systematically faced?

In the case of STM32F756NG, there is already a limitation described in the errata sheet of the product 'Extra data written in the FIFO at the end of a read transfer'.  

This limitation should be already implemented in the 'stm32f7xx_hal_qspi.c'. Are you using last version of STM32CubeF7 package Daniel.Blanchard‌? Are you in the same conditions as the limitation?

In STM32F765IGT, this limitation was fixed, so you don't find it in related erratasheet..

peter.olsson‌, please make sure that really transferred data is aligned with DMA configuration.

-Amel

[Peter Olsson]

Posted on November 22, 2017 at 08:42

Amel,

Thanks for the reply. I will try to rip out some code that can be used to reproduce the issue. However, I'm quite busy for the moment, so it might take some time before I report back.

I've looked through my code several times, and I can't find any issues in there. The error seems impossible to trigger when running in debug mode. When running in release mode it is triggered after a couple of minutes (LCD contents updated at 10Hz, loading all bmp/font data from QSPI flash). DMA buffers are aligned at 32 byte boundaries, to make sure that D-cache can be cleaned/invalidated safely.

When reading data from flash, I do it like this (done from main loop):

1. Reset flag 'rxCompleted' to 'false'
2. Call HAL_QSPI_Command() to setup address, read length etc.
3. Call HAL_QSPI_Receive_DMA() to start receiving data using DMA
4. Wait for the flag 'rxCompleted' to be set to 'true'.
5. In HAL_QSPI_RxCpltCallback() I set the 'rxCompleted' flag to 'true' (called from ISR)

This works just fine, but what happens once in a while in release mode, is that 

HAL_QSPI_Command() fails, since 'QSPI_FLAG_BUSY' is still set, so it eventually times out. I would assume that after HAL_QSPI_RxCpltCallback() has been called, the 'QSPI_FLAG_BUSY' should be reset. But somehow this isn't true all the time.

As I said, I will try to create some sample code that can recreate the issue, but it might take a couple of weeks before I get back to you.

Regards,

Peter Olsson

[Amel NASRI]

Posted on November 29, 2017 at 10:22

Hi

peter.olsson

‌,

Back to your case, we still wait for your sample code.

Meanwhile, could you please check if 'busy' flag is set in QSPI register when problem occurs. This should help us to understand either the problem is related to HAL state machine or QSPI peripheral.

-Amel

[Daniel Blanchard]

Posted on November 20, 2017 at 15:45

HI Amel.

I already read the errata you mentioned.

Although I am not completely in the errata conditions (Simple Data Rate is used), I can tell :

- At the end of the reading (Indirect mode), the BUSY flag becomes inactive,

- Despite we are not in the errata condition, my software performs an ABORT at the end of the reading (one of the preconised workarounds),

- I do not use Stm32CubeF7 (neither the last version, nor any one else). I self-developped a QSPI driver (constraint : no dead or inactive code).

- And sorry, I can not 'share' the code I developped. I tried unsuccessfully to reproduce the phenomena on an evaluation board (even on our custom board, it is not obvious to determine which conditions make the issue appearing or not).

BR

Daniel

[Peter Olsson]

Posted on February 14, 2018 at 11:36

Hi Daniel,

Have you had any more progress on this? As I mentioned in another comment, it seems my issue is identical to yours. Have you tried to disable the D-cache? For me it did wonders, at least it seems so (I've just been trying for a short period of time). After doing that I was able to remove the workaround with QSPI abort.