FMC asynchronous wait management

[regjoe]

Hello,

I'm using STM32H75x and NOR flash e.g. IS29GL064. I get the NOR demo running but I'd like to do modifications in order to get rid of all the polling stuff.

According to the demo, the FMC is configured like this

 hnor1.Init.NSBank = FMC_NORSRAM_BANK3;
 hnor1.Init.DataAddressMux = FMC_DATA_ADDRESS_MUX_DISABLE;
 hnor1.Init.MemoryType = FMC_MEMORY_TYPE_NOR;
 hnor1.Init.MemoryDataWidth = FMC_NORSRAM_MEM_BUS_WIDTH_16;
 hnor1.Init.BurstAccessMode = FMC_BURST_ACCESS_MODE_DISABLE;
 hnor1.Init.WaitSignalPolarity = FMC_WAIT_SIGNAL_POLARITY_LOW;
 hnor1.Init.WaitSignalActive = FMC_WAIT_TIMING_BEFORE_WS;
 hnor1.Init.WriteOperation = FMC_WRITE_OPERATION_ENABLE;
 hnor1.Init.WaitSignal = FMC_WAIT_SIGNAL_ENABLE;
 hnor1.Init.ExtendedMode = FMC_EXTENDED_MODE_DISABLE;
 hnor1.Init.AsynchronousWait = FMC_ASYNCHRONOUS_WAIT_ENABLE;
 hnor1.Init.WriteBurst = FMC_WRITE_BURST_DISABLE;
 hnor1.Init.ContinuousClock = FMC_CONTINUOUS_CLOCK_SYNC_ASYNC;
 hnor1.Init.WriteFifo = FMC_WRITE_FIFO_ENABLE;
 hnor1.Init.PageSize = FMC_PAGE_SIZE_NONE;

I wonder here about the "FMC_ASYNCHRONOUS_WAIT_ENABLE". I can remember that there are pretty old µC out which are waiting for a slow memory to get ready by using a wait signal. While memory is busy the µC is stalled and is inserting wait states. RM0433 seems to implicate this

According to the IS29GL064 datasheet, the flash seems not to make use of the RD/BSY (connected to FMC_NWAIT) signal during READ. Only during WRITE this signal tells the µC that it is busy programing data or that its receive buffer is full.

In the demo, all the WAIT timing seems to be handled in SW. In the demo the FMC_NWAIT pin is polled using HAL_NOR_GetStatus() after each single HAL_NOR_Program() call or after HAL_NOR_ProgramBuffer(). I think it would make sense to use IRQ fired by FMC_NWAIT instead of polling the pin.

If so, can I change the configuration to FMC_ASYNCHRONOUS_WAIT_DISABLE or does this have any drawback? Is there any recent asynchronous NOR flash that is using the NWAIT pin during READ/WRITE cycle and which must be handled by the FMC in hardware?

In the demo all data is written word by word. What about using DMA, does the NWAIT signal probably synchronize the flash data transfer with the DMA?

Thank you.

[waclawek.jan]

In case of FLASH, the programming times are too long (thousands of processor cycles) to be practical to use the hardware WAIT mechanism. The processor after writing data would be stalled for the duration of write.

In case of software handling, if you manage things smartly (e.g. use interrupts instead of polling the WAIT signal), processor can do some other useful work while data are written.

Similarly, if you use DMA, the whole DMA (i.e. all of its streams) would be stalled if hardware WAIT is used. 

JW

 

[regjoe]

Hello @waclawek.jan 

If I get you right, the CPU would be blocked if WAIT mechanism is configured and the flash is toggling its RDY/BSY pin during CPU READ/WRITE flash memory operation. It is the same mechanism as if CPU is fetching code from NOR flash?

DMA would free the CPU from time-consuming register polling, especially useful if memory access is quite slow, as this is the case with asynchronous NOR flash, I think.

Regarding the HAL function HAL_NOR_Program(), the asynchronous NOR flash protocol requires multiple register accesses for a single data transfer. This makes it unusable for DMA.

HAL_NOR_ProgramBuffer() and HAL_NOR_ReadBuffer() I guess can be modified in order to use DMA. But obviously not all NOR flash do support the program buffer protocol and command.

Regarding this post https://community.st.com/t5/stm32-mcus-products/stm32l4s7zit-can-fmc-be-used-with-dma/td-p/187026 DMA should be fine with FMC. Has anybody checked this out e.g. with NOR flash and SDRAM?

Thank you