stm32h7 GPIO registers have consistently misnamed bitfields

[baldwin1974]

I am trying to develop additions to the yaml device file for the stm32h7x3 svd, but I am stuck on an inconsistency. As background, in most of STMicro's svd files, there appears to be a preference of adding an "R" or "r" after a bitfield, as that is consistent with the same practice for registers. (This is not a thoroughly confident assertion, it just looks that way from scanning some random svd files.) For example, a bitfield for GPIOA::MODER is usually moder0 .. moder15.

Unfortunately, and in contrast to most other svds, in the stm32h7x3 svd file, that practice is not uniformly followed: I've found it is mode0 .. mode15, ospeed0 .. ospeed15, lck0 .. lck15, and so on. (The trailing r is missing.) However, in the structs the "R" remains. It seems to me that this inconsistency might lead to errors.

I'd like to make it consistent with the other yaml files because then I could include your gpio_v2.yaml common patch. I could then work through the svd and datasheet to see if other common patches can be assimilated. (There seem to be similar problems, outside of the GPIO blocks.)

I wonder if you could add that function to your patch script? It looks to me like modifying fields cannot be done using wildcard matches right now. Otherwise, I am left with manually updating the bitfields. :( The only other approach I can think of is an individually-crafted sed script.

[adamgreig]

Wow, that's annoying. The RM0433 for the STM32H7x3 specifically uses the same MODER, etc, field names as the older families, so I think they should indeed be corrected in the SVD. Note not all GPIO fields are: LCK3, BS2, OT13, but MODER8, OSPEEDR0, PUPDR14, IDR1, ODR2, BR13, AFR5. I think the best bet is to follow the ref man even though it's still not exactly consistent.

Sadly renaming can't work with wildcards because there's no way to tell it what the new name should be as a pattern. I'll see if there's any easy or obvious way to do this.

[adamgreig]

Sorry, dropped the ball on this one but will try and get it sorted out tomorrow evening. There's probably enough accumulated fixes to release new versions of everything too.