[hal_stm32 v1.12.1] HAL_OSPI_Transmit_DMA() not working

[rolandash]

Describe the bug

stm32h7xx_hal_ospi.c: HAL_OSPI_Transmit_DMA() used to work well in earlier revision. After update to latest revision, this function stops working.

The problem seems to be caused by an amendment to the following line in latest revision in this function:
zephyrproject-rtos/hal_stm32@cd7e003#diff-21e15dc03dfb0fe696366cf246ffc122e5e441709a61c02fbef072fa815b5b86R1498-R1499

Obviously the maintainer was trying to correct the counter-intuition of the naming scheme of in this line when calling the HAL_MDMA_Start_IT() function, which is , the order of 'source address' and the 'destination address' parameters. Unfortunately the underlying layer, whether zephyr or the chip hardware, does not work as the naming scheme suggested. The function stops working. Revert this line to previous revision smooth everything.

It is suggested to revert this line to previous revision.

Regression

• This is a regression.

Steps to reproduce

1. Setup DMA and sssemble an OSPI command and then call HAL_OSPI_Transmit_DMA() from App, the function executed quitely with nothing happen on the bus.
2. Revert this line to its previous version, and watch the OSPI clock and data show up on the bus.

Relevant log output

Impact

Showstopper – Prevents release or major functionality; system unusable.

Environment

MacOS 15.x / M4 chip,
Zephyr SDK
Commitment: 5cbc642b1a79d4f373b1587f8c3027f31bf0d30c

Additional Context

No response

[github-actions]

Hi @rolandash! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[kbidani]

The arguments are in the wrong order. According to the STM32 HAL documentation, the function prototype is:
HAL_MDMA_Start_IT(hmdma, SrcAddress, DstAddress, BlockDataLength, BlockCount)
The first argument after the handle should be the source address (where data comes from).
The second argument should be the destination address (where data goes).

[rolandash]

Perhaps the document needs to be verified if it is consistent with the actual implementation?
A simple test can validate the issue before the formal release.

[kbidani]

Perhaps the document needs to be verified if it is consistent with the actual implementation? A simple test can validate the issue before the formal release.

I have tested both before and after the latest revision (v1.12.0), and I can confirm that the bug is present.
PR link: zephyrproject-rtos/hal_stm32#307

[FRASTM]

should this issue be closed as the hal is now updated ?

[kbidani]

should this issue be closed as the hal is now updated ?

yes.