search

espressif / svd

SVD files for Espressif devices
Apache License 2.0
55 stars 2 forks source link

Name `IO_MUX_GPIO$n_MCU_OE` in tag `field` is missing a %s placeholder #1

Closed 9names closed 3 years ago

9names commented 3 years ago

$ svd2rust --version svd2rust 0.19.0 ( )

$ svd2rust -i ESP32C3.xml [ERROR svd2rust] In device ESP32C3

Caused by:
    0: In peripheral `IO`
    1: In cluster `Configure Registers`
    2: In register `IO_MUX_GPIO%s_REG`
    3: Parsing field #0
    4: Name `IO_MUX_GPIO$n_MCU_OE` in tag `field` is missing a %s placeholder
georgik commented 3 years ago

Thank you @9names.

@saramonteiro @jessebraham PTAL

We should also include svd2rust validation as GitHub Action. IMHO dispatched GitHub Action should be sufficient. What's your opinion?

9names commented 3 years ago

We used Actions for SVD validation for bl602-svd - might be a good starting point if you decide to go this way. https://github.com/pine64/bl602-svd/blob/main/.github/workflows/ci.yml

saramonteiro commented 3 years ago

Hi @9names thank you very much for your report on this. We're in the very beginning of svd automatic generation and feedback is pretty welcome. I'll investigate the issue on our generator and submit a newer fixed version.

jessebraham commented 3 years ago

I have forked this repository and created a new branch where I have begun work on a verification workflow. This was inspired by the bl602-svd repository. It is configured to run only when manually dispatched.

SVDConv and xmllint are both used for verification. Both are allowed to run to completion rather than killing the workflow if/when warnings are generated. I'm not sure if both are necessary as xmllint is already checking against the schema, but I am not very familiar with either tool so I will look into it a bit more. You can see a test run of these checks here.

I have since added a step which generates a Peripheral Access Crate (PAC) from the SVD using svd2rust, however this is currently failing due to some issues with the SVD. Manually making the required changes and running the script results in success on my local system.

Unfortunately since there is no Cargo.toml file present in the repo we are unable to build the PAC, meaning there are potentially still issues that can sneak through the verification process. Replicating the full PAC here just for testing probably falls outside the scope of this repo, however.

If anybody has any feedback on this workflow please let me know!

saramonteiro commented 3 years ago

@jessebraham it seems good. I also have used python cmsis-svd package, which is also a parser. I don't know which one fits better xmllint.

Regarding SVDConv seems to be as convenient as svd2rust for checking the generated peripheral files. The advantage of using SVDConv is that we can check many other other compliance that in the future
may be useful for debugging purpose when integrating it to Eclipse for example.

BTW, did you get to install the ARM::CMSIS Pack?

jessebraham commented 3 years ago

This issue has been resolved in #4.