STM32G4 dithering + DMAR + 16bit access

[ledvinap]

There is glitch when accessing timer registers using DMA

- Halfword memory to halfword peripheral DMA transfer

- DMA target is TIM15->DMAR, configured to write ARR register.

- TIM15 dithering enabled

Under these conditions, bits from ARR[3:0] will end up in ARR[19:16] and will be used as part of timer period.

Using word (32bit) transfer destination fixes this problem. This behavior is undocumented and it does take some time to find it.

[waclawek.jan · Accepted solution]

While surprising, this behaviour comes from first principles:

When dithering is enabled, TIMx_ARR is not a 16-bit register anymore, it has 20 active bits thus is effectively a 32-bit register.

As documented in AHB/APB bridges subchapter of System and memory overview chapter, 16-bit writes to APB peripherals are converted by AHB/APB bridge to 32-bit writes by duplicating the lower 16 bits to the upper part of bus.

To see this effect in other context, try to perform a 16 bit write from processor to ARR in dithering mode, or to ARR or any other 32-bit register of TIM2 or TIM5.

JW

[ledvinap]

Thank you very much! Now, it is obvious (and explains other problem I was trying to pinpoint)..

Petr

[waclawek.jan]

Hi Petr,

> it is obvious

I was thinking about this problem while travelling to work, and no, now I don't think it's obvious.

I checked in RM0440, and the TIM15-TIM17 chapter's register subchapter does not tell at its intro the allowed access width. (The same intro in TIM2-TIM5 allows both 16-bit and 32-bit accesses.)

Thing is, that while the AHB-APB bridge does duplicate data for 8- and 16-bit writes, the width/lane information is propagated along the data and the individual peripherals may or may not honor the width/lane signals. In other words, if a peripheral is configured so that it ignores the bus width, then if the peripheral does have effectively 32 bit registers, only 32-bit accesses are allowed due to the reduplication. OTOH if the peripheral is either purely 16-bit (i.e. has only 16-bit registers, as is the case of TIM15-TIM17 in older STM32), or if it does honor width/lane, it can be accessed by either 16- or 32-bit accesses (the former would change only the lower or upper 16-bits in given 32-bit register).

So, the question here is, how are TIM15-TIM17 modules configured in 'G4, and this ought to be documented through the description of allowed access width at the beginning of the registers' description subchapter.

( @Imen.D , can please this information be added to the RMs as appropriate? Thanks.)

> and explains other problem I was trying to pinpoint

Can you please tell what problem?

Thanks,

Jan

[Imen.D]

Hello All,

Thank you @waclawek.jan for flagging this topic for me!

An internal ticket number 181547 is submitted in order to add the information in the RMs.

(PS: Ticket number 181547 is an internal tracking number and is not accessible or usable by customers).

[waclawek.jan]

Thanks, @Imen.D !

JW

[ledvinap]

Hi Jan,

>> it is obvious

>I was thinking about this problem while travelling to work, and no, now I don't think it's obvious.

I was searching in wrong direction. It seemed that actual dithering (nonzero dither bits) was causing the problem. In beginning, I assumed that counter does not generate events (I did not wait long enough for timer to expire). Also,  everything looked like it is only related to register access through DMA and DMAR (I did use 32 bits without realizing it when accessing register directly). 

With better APB knowledge, I'd probably realize source of problem much earlier. 

Petr