HAL library bug in OSPI driver

[trs]

Source and destination parameters are incorrectly placed in the following code:

stm32h7xx_hal_ospi.c

Line 1496

HAL_OSPI_Transmit_DMA function

if (HAL_MDMA_Start_IT(hospi->hmdma, (uint32_t)pData, (uint32_t)&hospi->Instance->DR, hospi->XferSize, 1) == \
HAL_OK)

[SofLit]

Hello,

Sorry I couldn't understand;

HAL_MDMA_Start_IT has the following definition:

HAL_StatusTypeDef HAL_MDMA_Start_IT(MDMA_HandleTypeDef *hmdma, uint32_t SrcAddress, uint32_t DstAddress, uint32_t BlockDataLength, uint32_t BlockCount)

So the 2nd input is the source and the 3rd one is the destination.

In stm32h7xx_hal_ospi.c / line 1496:

 if (HAL_MDMA_Start_IT(hospi->hmdma, (uint32_t)pData, (uint32_t)&hospi->Instance->DR, hospi->XferSize, 1) == \

So pData is the source which is located in the RAM and the destination hospi->Instance->DR is the data register of the OSPI.

Could you please clarify? or am I missing something?

[trs]

Now tell me how you would call HAL_MDMA_Start_IT() function when you want to send data from MCU to a OSPI memory chip, and how you would call this function when you want to receive data from OSPI memory chip to MCU. By how, I mean where would you place source and destination addresses in both cases, show me example in pseudo code.

[SofLit]

To send data from a memory to OSPI using DMA you need to call :  HAL_OSPI_Transmit_DMA():

Line 1496: if (HAL_MDMA_Start_IT(hospi->hmdma, (uint32_t)pData, (uint32_t)&hospi->Instance->DR, hospi->XferSize, 1) == \
HAL_OK)

To receive data from OSPI to a memory using DMA you need to call : HAL_OSPI_Receive_DMA():

line 1600: if (HAL_MDMA_Start_IT(hospi->hmdma, (uint32_t)&hospi->Instance->DR, (uint32_t)pData, hospi->XferSize, 1) == \

Hope I answered your question!

[trs]

Some one fixed it:

https://github.com/STMicroelectronics/stm32h7xx_hal_driver/commit/cff8a947c901b8db3f94f731e3aef516c7c60d8b

[SofLit]

So here the issue is on the receive and not on the transmit contrary to what you posted at the beginning.

[trs]

Good you understand it now.

[SHs]

Hello @trs,

The issue has been identified and resolved internally. The fix is now available on GitHub and will be included in the upcoming release. 

Thank you for your contribution.

Internal ticket number: 179252