Combined PWM: Inconsistend RM description and error in STM32H743xx.h

[flyer31]

Thank you for the new "Combined PWM Mode" for the main timers... . This really was missing in STM32F4, creating 2-3 phase shifted PWM signals with just one timer... . This is now VERY nice with STM32H7.

But the discription in RM (July 18) 37.3.13 is somehow contradictory:

- There it says concerning channel pair 1/2 (or 3/4): "for instance, one in Combined PWM mode 1 and the other one in Combined PWM mode 2".

- but 5 lines further down in the sample description for Figure 381, it says "Channel 1 is configured in Combined PWM mode 2, Channel 2 is configured in PWM mode 1" (I think there it should say "Channel 2 is configured in COMBINED PWM mode 1" - at least this works).

- Figure 381 also has a bit strange vertical axis descriptions ... what do you mean by "OC1'" and "OC2'" and "OC1REF'" and "OC2REF'"? (I am quite sure this better should mean "OC3" and "OC4" and "OC3REF" and "OC4REF"?)

Generally I think it is not very nice to use the terms "OC1".. in this figure 381 I think, as in Figure 343 these terms "OC1"... are used synonymus with the outputs ... I think it would be much more useful to use the terms "CCR1"... in the figure 381 (als also in the 37.3.13 description at the start.

And why do you insert the "OC1REFC'" signal in this figure 381 - isn't this quite a mixup? (As I understand, you want to show the combined AND mode for channel 1, then please concentrate on this also in figure 381 ... so it would be nice so show there the combined AND for channel pair 1-2 and pair 3-4 ... if you are so excited about the further possibility to combine by OR, you better should spend a second figure for the OR options there ... but I think most people are excited enough to see that it is possible to adjust the 2 phases against each other, to alone the AND option is perfectly fine, the OR option probably more some academic further interest for very few "special users").

In the STM32H743xx.h concerning this "combined PWM" there is quite an severe error. These are the definitions there for CCMR1_OC1M, This is quite evidently wrong, for OC3M and OC4M the correct numbers are:

CCMR1_OC2M, CCMR2_OC3M, CCMR2_OC4M:

#define TIM_CCMR1_OC1M_Msk        (0x1007U << TIM_CCMR1_OC1M_Pos)              
#define TIM_CCMR1_OC1M_3          (0x1000U << TIM_CCMR1_OC1M_Pos)
...            
#define TIM_CCMR1_OC2M_Msk        (0x1007U << TIM_CCMR1_OC2M_Pos)              
#define TIM_CCMR1_OC2M_3          (0x1000U << TIM_CCMR1_OC2M_Pos)            
...
#define TIM_CCMR2_OC3M_Msk        (0x7U << TIM_CCMR1_OC1M_Pos)              
#define TIM_CCMR2_OC3M_3          (0x1000U << TIM_CCMR1_OC1M_Pos)
...            
#define TIM_CCMR2_OC4M_Msk        (0x7U << TIM_CCMR1_OC2M_Pos)              
#define TIM_CCMR2_OC4M_3          (0x100U << TIM_CCMR1_OC2M_Pos)            
...

This is quite evidently wrong, for OC3M and OC4M the correct numbers are:

#define TIM_CCMR2_OC3M_Msk        (0x1007U << TIM_CCMR1_OC1M_Pos)              
#define TIM_CCMR2_OC3M_3          (0x1000U << TIM_CCMR1_OC1M_Pos)
...            
#define TIM_CCMR2_OC4M_Msk        (0x1007U << TIM_CCMR1_OC2M_Pos)              
#define TIM_CCMR2_OC4M_3          (0x1000U << TIM_CCMR1_OC2M_Pos)            
...

... as I complained already in my "Hello World" post, I think that this STM32H743xx.h file is completely over-redundantly blown up ... every software engineer will learn in his very first beginning at some good software prof, that it is extremely dangerous and in-efficient to create redundant coding ... the guys how invented this new "stm32h743xx.h" file definitely possibly missed that.