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

[Amel NASRI]

Posted on April 18, 2018 at 12:57

 Hi peter.olsson‌,

I come back to this thread -after long time, sorry for this.

We re-checked your case and we suspect that the root cause of the behavior you are seeing is that the Cortex-M7 may issue some speculative read accesses on some memory interfaces.

 The recommendation to avoid side effects of this feature is to configure properly memories even for non-used regions. This means that the MPU has to be configured in the appropriate way even when using indirect mode, and not the memory-mapped mode.

An example of configuration is what we describe in the AN4861 where QSPI is used in a typical graphic application.

Being in indirect mode, all the QSPI area has to be configured as a strongly ordered memory.

With such MPU configuration, you can keep the D-cache enabled.

 To confirm this assumption, it will be helpful if you can make tests based on this recommendation and keep as informed about the status (Sorry, I know it is a late reply and you maybe you are no more working on this at the moment).

Thanks.

-Amel

[Peter Olsson · Accepted solution]

Posted on April 19, 2018 at 15:19

Hi Amel,

Thanks for your reply.

It seems this change solves the issue!

I added the following code, and after that things seems stable - at least so far.

MPU_InitStruct.Enable = MPU_REGION_ENABLE;

MPU_InitStruct.Number = MPU_REGION_NUMBER1; MPU_InitStruct.BaseAddress = 0x90000000; MPU_InitStruct.Size = MPU_REGION_SIZE_256MB; MPU_InitStruct.SubRegionDisable = 0x0; MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0; MPU_InitStruct.AccessPermission = MPU_REGION_NO_ACCESS; MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_DISABLE; MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE; MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE; MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;