All Linked list DMA configurations generated by Cube, unnecessarily fail HAL checks

[okz]

For processors with GPDMA peripherals and "linked lists" support, Cube generates sufficient code for linked list Node initialisations and uses HAL_DMAEx_List_Init correctly. But doesn't bother populating the DMA Channel Init structure with the HAL_DMA_Init, leaving Channels SrcDataWidth, DestDataWidth elements unconfigured.

This is probably correct and sufficient to configure the peripheral, however HAL DMA functions only check the DMA Init structure, and not the Node structure, and unnecessarily reject the configuration:

For example:

HAL_StatusTypeDef HAL_SPI_Transmit_DMA(SPI_HandleTypeDef *hspi, const uint8_t *pData, uint16_t Size)
{

...
  /* Packing mode management is enabled by the DMA settings */
  if (((hspi->Init.DataSize > SPI_DATASIZE_16BIT) && (hspi->hdmatx->Init.SrcDataWidth !=  DMA_SRC_DATAWIDTH_WORD) && \
       (IS_SPI_FULL_INSTANCE(hspi->Instance))) || \
      ((hspi->Init.DataSize > SPI_DATASIZE_8BIT)  && (hspi->hdmatx->Init.SrcDataWidth ==  DMA_SRC_DATAWIDTH_BYTE)))
  {

    return HAL_ERROR;

Above check on SrcDataWidth fails the call, as it was never initialised in the HAL_SPI_MspInit function

The issues made worse, as Cube preferes to use "linked lists" for circular buffers, rather than a standard buffer, meaning Cube generated code with circular buffers don't work with HAL drivers.

Kind regards, Oz

[TOUNSTM]

Hello @okz,

Unfortunately, I couldn't reproduce the behavior. Could you please provide the steps to reproduce this issue? Additionally, could you let me know which series you are working on?

Kind regards,