DMA_SetConfig() function call not backward compatible with STM32L4 HAL

This isn't a bug as such, but it is a trap for anyone porting from STM32L4 (and maybe other older STM32s) to the U5 HAL.

The parameter SrcDataSize in the function DMA_SetConfig() has a different meaning from STM32L4 - this is due to the difference between the U5 GPDMA GPDMA_CxBR1 register BNDT field - which is the number of bytes to transfer (RM0456 17.8.12) and the L4 DMA DMA_CNDTRx register NDT field which is the number of DMA transfers (RM0432, 11.6.4).

If the source and destination datawidths are both bytes then DMA_SetConfig() functions identically on the U5 and L4, but if the datawidth is half-word or word then on the U5 the DMA transfer ends after either 1/2 or 1/4 of the DMA is complete since each transfer counts for 2 or 4 bytes,

static void DMA_SetConfig(DMA_HandleTypeDef const *const hdma,
                          uint32_t SrcAddress,
                          uint32_t DstAddress,
                          uint32_t SrcDataSize)   <<< this parameter is a byte count on the U5 and a transfer count on L4

https://github.com/STMicroelectronics/STM32CubeU5/blob/2e2b3e4733ddcde7af1e91f1c27ef7bea84389ce/Drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_dma.c#L1588

This difference in functionality affects any callers of either HAL_DMA_Start() or HAL_DMA_Start_IT(). It's possible to fix this with conditional compilation in the application code, but it's not ideal to have a near identical HAL API with different functionality. In theory DMA_SetConfig() could read the burst length configured in the hdma struct and multiply the SrcDataSize accordingly and I think that this would lead to a consistent API behavior on the U5 to the L4 - but perhaps it's too late to make this change since it would likely break existing applications. Perhaps a comment above the function prototypes to draw attention to the difference ?

STMicroelectronics / STM32CubeU5

DMA_SetConfig() function call not backward compatible with STM32L4 HAL #22