Hardware bug STM32F11 in Timer DMA mode (PWM Generation)

[rzong.1]

I wanted to generate PWM Waveforms with nucleo F411and found a severe bug in the hardware. Maybe it is described in the errata sheet, but I found nothing.

bug:

DMA is dependent on data send on DMA stream. Sometimes DMA transfer is not done. (DMA circular mode. the transfer complete interrupt rate goes down in the error case.)

It is reproducable even with a modified example of the CubeMX package.

This example I used:

Repository/STM32Cube_FW_F4_V1.24.2/Projects/STM32F411RE-Nucleo/Examples_LL/TIM/TIM_DMA/

change 4 lines in Src/main.c of the project to produce the error:

original:

1)

LL_TIM_SetAutoReload(TIM3, __LL_TIM_CALC_ARR(TimOutClock, LL_TIM_COUNTERMODE_UP, 17570));

new:

LL_TIM_SetAutoReload(TIM3, 511);

2)

aCCValue[0] = (uint32_t)(((uint32_t) 75 * (LL_TIM_GetAutoReload(TIM3) - 1)) / 100);

to: aCCValue[0] = 510;

3)

aCCValue[1]=510;// = (uint32_t)(((uint32_t) 50 * (LL_TIM_GetAutoReload(TIM3) - 1)) / 100);

to: aCCValue[1]=510;

4)

aCCValue[2] = (uint32_t)(((uint32_t) 25 * (LL_TIM_GetAutoReload(TIM3) - 1)) / 100);

to: aCCValue[2] = 0;

now the with oscilloscope monitored waveform has a period of 4 PWM cycles instead of 3. transfer complete interrupt rate goes down respectively.

If You change 4) to aCCValue[2] = 1 or another number period is 3 PWM cycles, all is ok.

cheers

[TDK]

aCCValue is just some value in memory. What register settings are causing the crash? Seems more likely it's related to an overflow than a hardware issue. Could be wrong.

[berendi]

How did you conclude that it is a hardware error?

[rzong.1]

The example program from st is quite simple. write 3 values into aCCValue[] and start a circular DMA to transport the values to the timer. then enter an endless loop. That should work with any allowed values in the buffer. I dont think, it is software related, because software is very simple.

I found this problem while developing my own software.

It is a bug report. anybody here from st?

Who is the correct recipient for bug reports?

ok. bug is either in the example program or in the hardware.

[berendi]

> bug is either in the example program or in the hardware.

No, there is a third option.

With your changes, the preloaded CCR is set to 0, and the CC match occurs one cycle later.

Nevertheless the original example is a mess, setting the nonexistent RCR, and enabling DMA requests on an unconfigured DMA channel.

[rzong.1]

thanks, that helps.

is it right that the DMA transfer is triggered by the CC match? Than I understand.

[berendi]

Using those LL wrapper functions makes it really hard to follow the code, but I believe so.

According to the reference manual, stream 7 channel 5 is the TIM3_CH3 request triggered by the compare event. The update event triggers the unconfigured stream 2.

[rzong.1]

error seems to be the st example.

but something is quite astonishing.

the sequence 510,510,0 delivers a period of 4

the sequence 510,410,0 delivers a period of 3

So I changed to stream2 and it seems to work fine.

p.s.

I dont line the LL wrappers too, but they are significantly faster than the slow HAL

[berendi]

> the sequence 510,510,0 delivers a period of 4

A DMA transfer requires 4 cycles to complete, triggering them in so close succession might delay the last request, or miss it completely. (This would apply to requests from one source. Concurrent requests from multiple sources would be properly queued).

> but they are significantly faster than the slow HAL

which is even harder to follow, and has a lot more bugs.

[rzong.1]

thanks for Your help