STM32F446 TIM2 CCR1 and DMAR registers appear tied together.

[DHase.1]

I've been trying to get TIM2 PWM (or even OC) to produce an output. When looking at the registers, using openocd w telnet, I find that setting 0x40000000 (the CR1 register) with 0x81 also sets the 0x4000004C (the DMAR) register. The reverse is the same.

Here is an example of setting CR1 (offset 0) and having it show up in the DMAR (offset 0x4C)

> mdw 0x40000000 32
0x40000000: 00000081 00000000 00000000 00000000 0000001d 00000000 00006801 00006868
0x40000020: 00000000 00005658 00000002 00008ca0 00000000 00000000 0000ffff ffffffff
0x40000040: 0000ffff 00000000 00000000 00000081 00000000 00000000 00000000 00000000
0x40000060: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> mww 0x40000000 0x1345678 [Set CR1]
> mdw 0x40000000
0x40000000: 00000278 [Read-back new setting]
> mdw 0x40000000 32 [Look at all the registers; 0ffset 4C now has 0x278!]
0x40000000: 00000278 00000000 00000000 00000000 0000001d 00000000 00006801 00006868
0x40000020: 00000000 0000800d 00000002 00008ca0 00000000 00000000 0000ffff ffffffff
0x40000040: 0000ffff 00000000 00000000 00000278 00000000 00000000 00000000 00000000
0x40000060: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

At the moment things are not making sense. This is a custom board so there is always the possibility that the processor was damaged during the assembly. However, I can configure the PB10 (associated with TIM2 CH3) for GPIO output; set & reset it and see the output change accordingly and many other features are working OK. Furthermore, dumping the registers shows the TIM2 counter counting and ARR reloading, etc.

Any thoughts and ideas are welcome.

[DHase.1 · Accepted solution]

The DMAR and CR1 registers are related via the DCR register. The default register settings do set a relationship between them such that loading either the DMAR or CR1 loads the other register, at least for the bit positions defined.

I found the main problem of the PWM not showing output was that the CCER register was not initialized. The discovery of the CR1 and DMAR register issue was a distraction (but something new learned).

[waclawek.jan]

As you've already discovered, DMAR is not a true register, rather, a "window" through which other TIM registered can be accessed. The internal pointer determining it's target increments upon every access (including from debugger) and when the count set in DCR is reached out wraps around to first register again as set in DCR.

Accesses before the wraparound have also the effect of triggering DMA accesses, that's how the whole DMAR/DCR machine works.

JW