Using SPI DMA at 16bit, dosent work on STM32H5

[spa23]

Hi. ST

There is an error in the code that is generated by CubeMx when you use 16bit in SPI DMA transfer.

Can be solved in the stm32h5xx_hal_msp.c file:

/* USER CODE BEGIN SPI4_MspInit 1 */
memcpy(&handle_GPDMA1_Channel1.Init,&NodeConfig.Init, sizeof(NodeConfig.Init));
/* USER CODE END SPI4_MspInit 1 */

 

maybe ST will look into it?

Using: 

STM32Cube FW_H5 V1.3.0

STM32CubeMX: 6.12.1

MCU: STM32H573IIKxQ

Best regards.

 

[Ghofrane GSOURI]

Hello @spa23 

CubeMX serves as a powerful tool for configuring STM32 microcontrollers and generating the corresponding initialization code based on user-selected parameters. However, it is essential for users to recognize that while CubeMX provides a solid foundation, it may not cover all specific application requirements.
Therefore, users should take the initiative to manually add or modify code to tailor the initialization process to their specific needs.
You can start the DMA transfer using the following function:
HAL_SPI_TransmitReceive_DMA(SPI_HandleTypeDef *hspi, const uint8_t *pTxData, uint8_t *pRxData,uint16_t Size)

Please check this post , it could be helpful.

THX

Ghofrane

[spa23]

Yes, but I would still call it a bug in CubeMx, since the settings that the user sets up, for example that it should use 16bit, are not set up correctly, In the generated files (.c/.h)
So when you then call HAL_SPI_TransmitReceive_DMA() it will not send data when you use 16bit, but only if you use 8bit.

Because the data in NodeConfig.Init is not copied/used, here it says that the SPI must run 16bit.

Still think ST should fix the bug in cubeMx.

 

Best regards

SPA

[Lukasz Nowak]

Hi @Ghofrane GSOURI 

I agree with @spa23 that this is a bug in CubeMx initialization code, and should be fixed.

To add more detail, the issue is that the handle_GPDMA1_Channel1.Init structure is not populated at all, by any code. And checks like this fail:

HAL_StatusTypeDef HAL_SPI_TransmitReceive_DMA(SPI_HandleTypeDef *hspi, const uint8_t *pTxData, uint8_t *pRxData,
 uint16_t Size)
{
[...]
 /* Packing mode management is enabled by the DMA settings */
 if (((hspi->Init.DataSize > SPI_DATASIZE_16BIT) && \
 ((hspi->hdmarx->Init.DestDataWidth != DMA_DEST_DATAWIDTH_WORD) || \
 (hspi->hdmatx->Init.SrcDataWidth != DMA_SRC_DATAWIDTH_WORD)) && \
 (IS_SPI_FULL_INSTANCE(hspi->Instance))) || \
 ((hspi->Init.DataSize > SPI_DATASIZE_8BIT) && \
 ((hspi->hdmarx->Init.DestDataWidth == DMA_DEST_DATAWIDTH_BYTE) || \
 (hspi->hdmatx->Init.SrcDataWidth == DMA_SRC_DATAWIDTH_BYTE))))
 {
 /* Restriction the DMA data received is not allowed in this mode */
 /* Unlock the process */
 __HAL_UNLOCK(hspi);
 return HAL_ERROR;
 }

It works with 8-bit SPI by pure accident - because DMA_SRC_DATAWIDTH_BYTE and DMA_DEST_DATAWIDTH_BYTE are defined as 0.

[Andrei Chichak]

This is VERY interesting. I'm having a problem with SPI and circular DMA with these processors and this post seems to partially get around my issue as well.

I'm using 20-bit transfers, but setting circular DMA ends up with the values of Init.DestDataWidth and the Init.SrcDataWidth both equal to zero. If you use DMA for transmit and receive, you use two DMA descriptors and the init code in HAL_SPI_MspInit sets them up nicely, but does not copy them from NodeConfig into the DMA handle.

The addition of the memcpy line in SPI1_MspInit 1 fixes one of the data widths, but the second cannot be patched as the value of NodeConfig.Init gets overwritten before it (doesn't) get copied into the DMA handle.

This is now on year 2 of this issue, has not been fixed in CubeMX 6.17.0 (which came out yesterday) and with Firmware H5 1.6.0 from 23 days ago.

Please see: https://community.st.com/t5/stm32cubemx-mcus/gpdma-spi-tx-rx-circular-mode-on-stm32h5-possible-incorrect/m-p/872374#M34856