mspi Flash NOR device with "Flash Auto-polling value"

[FRASTM]

What is the way to wait pin polling for WEL or WIP bits of a NOR flash ?

When implementing the MSPI device for one octo-spi NOR (example the Macronix MX25LM51245), it appears that some commands sent to the flash are polling for a bit of the its status register to be declared as "complete" or "ready"

In the drivers/flash/spi_nor.h this is known as / Flash Auto-polling values / a combination of a

• Match value
• Match Mask
  to read the status Register in a loop (with a Timeout guard) and poll the associated bit
  Typically, this sequence is implemented in the following situations:

1. Waiting for the NOR memory ready : read status register and wait for MEM_RDY bit

• Match value = SPI_NOR_MEM_RDY_MATCH
• Match Mask = SPI_NOR_MEM_RDY_MASK

2. Setting the NOR memory in write_enable, read status register and wait for WREN bit

• Match value = SPI_NOR_WREN_MATCH
• Match Mask = SPI_NOR_WREN_MASK

3. NOR flash in erase/program complete: read status register and wait for WEL bit

• Match value = SPI_NOR_WEL_MATCH
• Match Mask = SPI_NOR_WEL_MASK

I did not find a clear solution to proceed.

What could be this equivalent implementation with a flash MSPI device on a MSPI (controller) bus ?

As long as the flash_mspi_xx device only talks with mspi_transceive function to the MSPI controller,

• which element to hold the match Value/Match Mask, to pass to the controller ?
• could a new cmd to the mspi_transceive ( (like cmd = MEM_RDY/WREN/WEL) handle this feature ?
• does the Flash device wait for corresponding bit position reading the NOR memory status register in a loop
• do we need another function beside the mspi_transceive for that purpose
• How does the flash block waiting for the bit matching : inside flash function or inside mspi controller function ?

Any help/suggestion welcome

[FRASTM]

Example of polling for erase/program completion:

[FRASTM]

refer to #78186
Where a mspi_stm32_status_reg() function is implemented with a xfer->xfer_mode = MSPI_REG

[erwango]

@swift-tk FYI.
(^^@anangl)

[swift-tk]

Hi,
First of all, the MSPI controller should not care what its device states are, I.e. the WEL or WEN or READY which the flash driver should manage.
When accessing (flash) device registers, it is recommended to use MSPI_PIO mode which in general are short and may be frequent for device state polling. The MSPI_DMA mode is used for access with larger size(>hundreds of bytes). There is no definitive boundary for when to use MSPI_PIO or MSPI_DMA as it may be hardware/platform specific.
So it is the command you pass to mspi_transceive that matters. The device configurations required to send that command also matter but they should be configured by mspi_device_config beforehand.

If device mode switching is involved between register access and memory access, the switching should be handled via mspi_device_config and the device state should be managed by the device driver.

[swift-tk]

which element to hold the match Value/Match Mask, to pass to the controller ?

No need to pass this to the controller. You should initiate a device register read operation via mspi_transceive and process the data returned.

could a new cmd to the mspi_transceive ( (like cmd = MEM_RDY/WREN/WEL) handle this feature ?

You could use whatever command you like.

does the Flash device wait for corresponding bit position reading the NOR memory status register in a loop

You could send the polling command repeatedly in a loop until condition is satisfied.

do we need another function beside the mspi_transceive for that purpose
How does the flash block waiting for the bit matching : inside flash function or inside mspi controller function

This function should be in the flash device driver.

[FRASTM]

thanks @swift-tk for your answers.
It appears that our stm32 mspi controller does have HW to control the match value/mask bits of the status register
This is done by the HAL_XSPI_AutoPolling_IT() function, programmed with the corresponding config.
That's why I have implemented a flash_mspi_nor_mx_status_read() in the flash driver, which makes gives the match value/mask bits to poll inside the MSPi controller driver. The mspi driver can block until flags are correctly set.

[FRASTM]

There is still a question for the flash_mspi driver to the mspi_stm32 driver : Usually, the flash_mspi is going to call mspi_transceive
The MSPI is preparing the command for the HAL command followed (or not ) by transmit / receive data (depending on the direction, async dma or PIO)
This time when we need to poll the WIP/WEL bit of the NOR status register, This is another HAL named HAL_AutoPolling
So the mspi stm32 needs to send a command fodistinguish :

1. send command in SYNC (example for RESET MEM)
2. send command and Receive Data in IT or DMA
3. send command and Transmit Data in IT or DMA
4. send command and AutoPoll NOR control register bit in IT

And I do not see a possible combination of async/ direction/xfer_mode to detect all those different actions to the hardware controller.

Even if this is splitted in : (example for RESET MEM, prepare for Reading, prepare for writing)

1. send command in SYNC
2. Receive Data in IT or DMA
3. Transmit Data in IT or DMA
4. AutoPoll NOR control register bit in IT

[FRASTM]

Should then the MSPI stm32 driver detect , identify that the flash_mspi driver is issuing a "special" command named
SPI_NOR_CMD_RDSR or SPI_NOR_OCMD_RDSR with different MEM_RDY_MATCH/MEM_RDY_MASK values to program the mspi controller and wait for autopolling ?

[swift-tk]

You can construct your own user context in a way that your MSPI stm32 driver knows what each mspi_transceive means, provided that it is all async.

And I do not see a possible combination of async/ direction/xfer_mode to detect all those different actions to the hardware controller.

I'm not sure I follow your point here

1.send command in SYNC : xfer_mode is MSPI_PIO, sync, direction MSPI_TX
2.Receive Data with DMA : xfer_mode is MSPI_DMA, async, direction MSPI_RX
Receive Data with IT : xfer_mode is MSPI_PIO, async, direction MSPI_RX, user context Autopoll is off
3.Transmit Data with DMA: xfer_mode is MSPI_DMA, async, direction MSPI_TX
Transmit Data with IT: xfer_mode is MSPI_PIO, async, direction MSPI_RX, user context Autopoll is off
4.AutoPoll NOR control register bit in IT : xfer_mode is MSPI_PIO, async, direction MSPI_RX, user context Autopoll is on

[FRASTM]

OK, I will try with the user context
However I am not really sure of how to prepare this struct mspi_context in the NOR flash mspi environment
There is nothing in the flash data or config to hold a mspi_callback_context.ctx
The flash mspi data has a

• struct mspi_xfer trans; which also holds its own struct mspi_xfer_packet packet
• struct mspi_xfer_packet packet;

[swift-tk]

OK, I will try with the user context However I am not really sure of how to prepare this struct mspi_context in the NOR flash mspi environment There is nothing in the flash data or config to hold a mspi_callback_context.ctx The flash mspi data has a

• struct mspi_xfer trans; which also holds its own struct mspi_xfer_packet packet
• struct mspi_xfer_packet packet;

I don’t think there is a strict requirement on the content of the flash data, but if you do save it in the flash data, you might have to lock it and unlock it.

If there is one thing that I don’t like about the flash API, it is the fact that all the write/read APIs seem to be sync. Unless that is changed, everything we do in the flash driver or below level can’t escape the fate of using lock and consideration for context switching. So I guess you could just leave it on stack for now if it isn’t too big.