Submit fixes for SVD files

[vinchatl]

Hi,

I noticed several times that SVD files contain errors compared to what's documented in MCU RMs.

The whole purpose of the https://github.com/stm32-rs/stm32-rs repository is basically to fix those errors and supply accurate SVD files for Rust embedded development on STM32 MCUs.

How are these SVD files written/generated ? Are RMs and SVDs written from the same source ?

Would it be possible to submit upstream patches to the SVD that would benefit to everyone, instead of submitting these patches to Rust cartes only ?

Have a great day

[Amel NASRI]

Hi @vinchatl ,

You can find latest updates of SVD files on st.com under STM32xx series > CAD Resources > SVD.

for example, for STM32H7 series, you find the package under https://www.st.com/en/microcontrollers-microprocessors/stm32h7-series.html#cad-resources:

These SVD files should be aligned with RM, but if you still note some discrepancies, please report them here in the community in separate threads.

We continuously consider reported issues regarding SVD files to maintain the packages.

Please note that I haven't enough knowledge on how RUST is using these SVD files and to which level is it updated with SVD files versions.

I hope this helps to clarify the situation.

-Amel

[vinchatl]

Hi @Amel NASRI,

Yes, thanks for the clarification !

Sorry for the tone of my first message, it feels a bit aggressive when reading it now.

As I understand, SVDs and RMs are either written by hand or generated separately, thus explaining the differences between them.

I know ST is pretty open and active with the Cube packages freely available on GitHub, so I thought there could have been repositories with SVDs for a whole device family. In such a case, one could have opened a Pull Request to directly propose fixes to the team in charge.

Can I report the issues here in this post or should I create another post ?

FYI the repo I linked above takes SVD files as input (updated from ST's CAD ressources you mentioned), provides some fixes when needed, describes possible values for each field of each register of each device, and automatically generates Rust "crates". These are kind of C++ classes with enums, get/set functions, etc., that provide low-level type-safe documented access to registers, a bit like what the CMSIS device description + LL library does. :)

Vincent