cancel
Showing results for 
Search instead for 
Did you mean: 

DMA on QSPI write only works when single stepping through the code

LKa.1
Associate

I'm using BL-475E-IOTA2 board (STM32L475) which comes with MX25R6435F Flash chip. I'm trying to using Quad SPI to write and read to/from the flash chip.

With free running the code(release mode):

  • If I don't use DMA when writing to the flash chip, it can read/write with free running (running in release mode) fine.
  • If I use DMA, it always fails when I send a write enable command to the flash chip:

in stm32l4xx_hal_qspi.c, HAL_QSPI_Command() returns HAL_BUSY.

With single stepping through the code, with DMA or no DMA, it writes and reads the flash chip fine.

I tried QSPI clock prescaler of 1,2,3 but it didn't help. Sys clk and HCLK (to DMA) is 80MHz

I also tried adding a 1s delay before and after writing the write enable command to the flash, but it still failed the same way.

What could cause this problem?

1 ACCEPTED SOLUTION

Accepted Solutions

>>What could cause this problem?

NOR Flash devices are relatively slow for Write and Erase cycles, it's a stateful process, and not one tuned to cramming down data.

The write buffer (page) is 256-bytes, writes will need to be decomposed into page aligned, and page sized (max) transactions. The memory will then need to come ready before other non-status commands can be sent.

Make sure the HAL DMA commands actually complete, the functions should return immediatly, and don't block, you'll need to do that via your own waiting/callback mechanics. I doubt DMA is going to be profoundly faster.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

View solution in original post

2 REPLIES 2

>>What could cause this problem?

NOR Flash devices are relatively slow for Write and Erase cycles, it's a stateful process, and not one tuned to cramming down data.

The write buffer (page) is 256-bytes, writes will need to be decomposed into page aligned, and page sized (max) transactions. The memory will then need to come ready before other non-status commands can be sent.

Make sure the HAL DMA commands actually complete, the functions should return immediatly, and don't block, you'll need to do that via your own waiting/callback mechanics. I doubt DMA is going to be profoundly faster.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
LKa.1
Associate

Thank you! Yep you're right the write and some command operations are slow. After writing data to the flash chip and before calling HAL_QSPI_AutoPolling() to wait for the memory to be ready, I have to wait for QSPI_HandleTypeDef.State to be HAL_QSPI_STATE_READY first (ie when it finishes writing all data).