cancel
Showing results for 
Search instead for 
Did you mean: 

Using SPI DMA at 16bit, dosent work on STM32H5

spa23
Associate III

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.

 

3 REPLIES 3
Ghofrane GSOURI
ST Employee

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

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.

spa23
Associate III

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
Associate III

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.