VERY SLOW QUADSPI READ ACCESS WITH A NOR FLASH CHIP

[anonymous.8]

Posted on May 23, 2018 at 20:21

Hi, all. I am using a STM32F765VGT6 chip accessing a Macronix MX25L51245GZ2I 512Mbit (64MByte) NOR FLASH chip over the QUADSPI interface. I am using the HAL QUAD SPI driver. The AHB bus is running at 216MHz.

The problem I am seeing is very slow read access, even though I am using the QUAD SPI data transfer mode. I can't get above 1.8MBytes/second transfer speed, even when reading a block of 4096 Bytes. I am using Polled indirect read mode currently. The clock pre-scaler in the QSPI_HandleTypeDef data structure is set to 1 meaning a clock diver ratio of 2 and I do measure the QUAD SPI bus speed at about 100MHz using a logic analyzer. The data is being read correctly so the bus is actually working, just very slowly. With that high a clock speed, I should be getting a read data transfer rate of close to 50MBytes/second.

The odd thing is, that the measured data transfer rate stays at 1.8MBytes/second even when I increase the clock pre-scaler value, thus reducing the clock speed. It is not until I make the clock pre-scaler a ridiculously high value like 59, (divider ratio of 60) that the data transfer rate starts to fall below 1.8MBytes/second. So there is something else, other than the clock speed, that is limiting the data transfer rate and I can't figure out what that is.

Does anyone out there have any ideas of experience with this?

Thanks.

[Tesla DeLorean]

Posted on May 23, 2018 at 21:04

>>Does anyone out there have any ideas of experience with this?

Not really, but something I can probably benchmark.

Are you doing this in memory mapped mode?

[anonymous.8]

Posted on May 25, 2018 at 20:07

I have a partial answer to this. The QUADSPI reads were in indirect mode using polling. This read was taking place in a FreeRTOS task with a few other minor tasks also running. Even though the task running the QUAD SPI read was the highest priority task, the other tasks, plus the

FreeRTOS 

overhead of task switching were still consuming CPU cycles away from the polled QSPI read.

When I switched to indirect interrupt mode for the QSPI reads, the data transfer rate improved to 8MB/second, much better than the 1.8MB/

second

with polled mode, but still not fantastic either. Then after I switched to DMA Mode, to eliminate as much dependency on CPU cycles as possible, it jumped to 26MB/s. Now that's more like it, and totally adequate for my application, but still not near the theoretical maximum of almost double that.

So next I am going to try memory mapped mode and see how fast that goes. UPDATE - In Memory  Mapped mode I get 29MB/s.

Incidentally, I also tried the indirect polled mode before the tasks were created and the task scheduler runs and got an even worse data transfer rate of only 1MB/s, so the above explanation may not be the whole story either.

[AVI-crak]

Posted on May 25, 2018 at 22:58

The program (indirect) mode is needed for recording, the memory display mode is intended for reading.

[Peter Chang]

MMP mode speed is better then indirect mode.

For improve indirect mode read performance need modify HAL.

Please reference to my attachment.

stm32f7xx_hal_qspi.c

HAL_StatusTypeDef HAL_QSPI_Transmit(QSPI_HandleTypeDef *hqspi, uint8_t *pData, uint32_t Timeout)

&

HAL_StatusTypeDef HAL_QSPI_Receive(QSPI_HandleTypeDef *hqspi, uint8_t *pData, uint32_t Timeout)