2024-11-27 04:35 AM
(1) TIM1_SMCR and TIM2/3_SMCR have different naming convetions for SMS / TS fields
i.e. for TIM1_SMCR there are SMS/SMS_1 and TS/TS_1 and for TIM2/3_SMCR, SMS1/SMS2 and TS1/TS2 respectively.
(2) Also TIM1_SMCR_TS_1 field has no enumerated values, while for TIM2/3_SMCR_TS2 there are, but wrongly described. TIM1_SMCR_TS & TIM2/3_SMCR_TS1 has enums for the range 0..7 only, ie. the TS1 field itself.
As described in the RM0492, those fields must be combined.
I think the easies way forward would be to provide enums only for the TS1 field, and add missing values:
B_0x10000:Internal Trigger 4 (tim_itr4)
B_0x10001:Internal Trigger 5 (tim_itr5)
B_0x10002:Internal Trigger 6 (tim_itr6)
B_0x10003:Internal Trigger 7 (tim_itr7)
B_0x10004:Internal Trigger 8 (tim_itr8)
B_0x10005:Internal Trigger 9 (tim_itr9)
B_0x10006:Internal Trigger 10 (tim_itr10)
B_0x10007: Internal trigger 11 (tim_itr11)
B_0x20000: Internal trigger 12 (tim_itr12)
B_0x20001: Internal trigger 13 (tim_itr13)
B_0x20002: Internal trigger 14 (tim_itr14)
B_0x20003: Internal trigger 15 (tim_itr15)
(and repeat that pattern for all other fields that are splitted acrose registers)
Then one can code by just shifting the chosen enum to the TS1 field position.
2024-11-27 07:33 AM - edited 2024-11-27 07:33 AM
Hello @hijax_pl,
I have forwarded this request internally to the relevant team via Internal ticket number: 197197 (this tracking number is only for ST reference, and not accessible or usable by customers).
Thank you again for your contribution.
2024-12-23 04:40 AM
Hello @hijax_pl,
The svd files has been updated and I attached the STM32H5 svd package here.
Note that for the "TS" field declared in two positions, we can't implement all of the enumeration values, which causes the appearance of a warning in this case.
To align with validation tools, we implemented this:
and the same for SMS filed :
Thank you again for the continued feedback; it is much appreciated!