Open sjorsdewit opened 1 year ago
Thanks for reporting the issue! I think stm32ral needs updating to handle some of the cluster syntax in SVD that stm32-rs now takes advantage of. It looks like dimIndex
is optional, so I don't think it's necessarily a bug in the stm32-rs patches, but I haven't checked that specific case yet.
Not sure about the overlapped registers - are they in fact the same register with two names (i.e. at the same address)? In which case I think stm32ral will merge them to a common name and add all fields to both of them, but perhaps the naming algorithm needs improving for that case.
The DOEP
and DIEP
clusters are at different addresses I think (offset 0x900
and 0xB00
according to RM0432 56.15.45). Maybe prefixing the register name with the cluster name in case of conflict could fix this? The resulting names would match those in the datasheet in this case.
Some context: I'm using stm32ral and have found some SVD bugs which I'd like to fix (stm32l4+ sdmmc peripheral). I'm planning to submit a PR to stm32-rs for this after I finish testing it.
While trying to get the stm32ral to build with the latest version of stm32-rs, I have come across some issues:
stm32ral.py doesn't seem to like the stm32u series svd files. Which is not too surprising given that this series is not currently supported by stm32ral. My workaround for now was to hack the Makefile so it doesn't match this series
stm32-rs contains fs_device_cluster.yaml which is not compatible:
DIEPCTL1
andDOEPCTL1
are renamed toCTL1
). I don't understand why or how to handle this case.I'm not super familiar with this codebase or the SVD file spec, so not sure whether the patch in stm32-rs should be changed or if stm32ral.py needs updating? For now I have simply removed fs_device_cluster.yaml on my local fork, which otherwise appears to build fine with the latest SVD files/patches.