gen-device-stm32: USB_OTG_FS groupName inconsistency causes not all of the correct types to be generated for wrapper #5154
Description
I was looking into the USB implementation for the stm32 family of processors when I discovered a problem in the generation.
For this family the use of the groupName is not consistant, in that the same name is used to mean different registers depending on which peripheral.
<peripheral>
<name>OTG_FS_GLOBAL</name>
<description>USB on the go full speed</description>
<groupName>USB_OTG_FS</groupName>
<baseAddress>0x50000000</baseAddress>
<addressBlock>
<offset>0x0</offset>
<size>0x400</size>
<usage>registers</usage>
</addressBlock>
<registers>
<register>
<name>FS_GOTGCTL</name>
<displayName>FS_GOTGCTL</displayName>
<description>OTG_FS control and status register
(OTG_FS_GOTGCTL)</description>
<addressOffset>0x0</addressOffset>
...
<peripheral>
<name>OTG_FS_HOST</name>
<description>USB on the go full speed</description>
<groupName>USB_OTG_FS</groupName>
<baseAddress>0x50000400</baseAddress>
<addressBlock>
<offset>0x0</offset>
<size>0x400</size>
<usage>registers</usage>
</addressBlock>
<registers>
<register>
<name>FS_HCFG</name>
<displayName>FS_HCFG</displayName>
<description>OTG_FS host configuration register
(OTG_FS_HCFG)</description>
...Is generating a single type for both using only the registers from the first peripheral:
type USB_OTG_FS_Type struct {
FS_GOTGCTL volatile.Register32 // 0x0
FS_GOTGINT volatile.Register32 // 0x4
...What it needs to do is to generate a separate type for each, since the registers are different. By changing each groupName to be unique in a test file, I end up with the expected different types:\
// USB on the go full speed
type USB_OTG_FS_GLOBAL_Type struct {
FS_GOTGCTL volatile.Register32 // 0x0
FS_GOTGINT volatile.Register32 // 0x4
...
// USB on the go full speed
type USB_OTG_FS_HOST_Type struct {
FS_HCFG volatile.Register32 // 0x0
HFIR volatile.Register32 // 0x4
FS_HFNUM volatile.Register32 // 0x8
_ [4]byte
...The simplest thing is probably to patch the SVD files for the USB_OTG_FS group in the stm32 family, since from my searching they are the only family that has this quirk.
Any thoughts @amken3d or anyone else on how to handle this?