MCU package 1.11.1
This is not a new problem but perhaps a new perspective. I answered regarding this in a previous post but wanted to bring up anew because of the change in tack.
The problem is this: After setting up an SPI channel for 16 bit transfer, I also enabled the associated DMA channels for the SPI Tx and Rx. The code generated would return an HAL_ERROR when attempting to use the HAL_TransmitReceive_DMA() call. The reason for the error is due to 16 bit transfer set in the SPI parameters but the DMA channels were still set to the default BYTE mode. Changing the DMA to HALF_WORD allows the cal to complete without error.
I realize it is up to the programmer to set these parameters correctly, however, I feel it is an oversite on ST's part to allow a condition that is guarantied to fail. In the middleware configuration for AZURE RTOS, checks are made for invalid configurations as well the pin configurator and the clock configurator. It seems that the nuances for SPI and DMA configurations have not been fully vetted or the HAL coders have not taken into account the use of CubeMx. I have not checked this with UART or other peripherals.
In any case if you get a HAL_ERROR from HAL_TransmitReceive_DMA() and the error is occurring adfter the check in stm32h7xx_hal_spi.c where it is commented:
/* Packing mode management is enabled by the DMA settings */
then you need to adjust the DMA channel for the correct data width.
Thank you for your feedback.
The point is that the flow controller can be either the DMA or the peripheral. Size should be selectable. Also, transfer size of source and destination could be independent... Source and destination addresses must be aligned on the data size as well.
I hope this makes it clearer!
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.