Confusion about length parameter in HAL_TIM_PWM_Start_DMA

[Wakka]

Hi,

I have NUCLEO-F411RE and NUCLEO-U575ZI-Q boards. When trying to implement a sine curve with PWM and a low-pass filter I stumbled into problems with HAL_TIM_PWM_Start_DMA.

I store the precomputed sine data in an array and call HAL_TIM_PWM_Start_DMA. 

... BEGIN: pseudo code

uint16_t pwmData[PWM_SAMPLES];

compute_sine_data(pwmData);

HAL_TIM_PWM_Start_DMA(&htimX, TIM_CHANNEL_1, (uint32_t *) pwmData, PWM_SAMPLES);

... END: pseudo code

It works fine on STM32F4, but I noticed only half of the data is present on the STMU575. Apparently HAL_TIM_PWM_Start_DMA has different semantics on the 2 MCUs. On STM32F4 the length seems to be with respect to Data Width in the timers DMA setting, and on STM32U575 it seems to be measured in bytes (regardless of the GPDMA settings).

In short:

STM32F4: HAL_TIM_PWM_Start_DMA(&htimX, TIM_CHANNEL_1, (uint32_t *) pwmData, PWM_SAMPLES);

STM32U5: HAL_TIM_PWM_Start_DMA(&htimX, TIM_CHANNEL_1, (uint32_t *) pwmData, 2*PWM_SAMPLES);

I noticed that HAL_TIM_PWM_Start_DMA is calling HAL_DMA_Start_IT on STM32F4 and TIM_DMA_Start_IT on STM32U5. 

So is this behavior a bug or a feature?

[waclawek.jan · Accepted solution]

> is this behavior a bug or a feature?

Both.

The GPDMA in 'U5 is different from both forms of DMA in older STM32 in that its transfer size is in bytes, see GPDMA_CxBR1.BNDT. Cube/HAL for U5 simply reflects this, see e.g. for this particular case description for the underlying function (although the description for HAL_TIM_PWM_Start_DMA() itself fails to say so). So, it's obviously an intention.

However, the basic promise of Cube/HAL is to provide a seamless migration between STM32 models and families, and in this regard it's a bug.

JW

[Andrew Neil]

---

@waclawek.jan wrote:

in this regard it's a bug.

---

Absolutely - but all too common.

It should always be explicitly stated what the "unit of measure" is.

[Wakka]

Thanks, as an old grump from the software industry, I would say that it is a basic no-go to have semantics in an abstraction layer depending on lower layers.