cancel
Showing results for 
Search instead for 
Did you mean: 

Your STM32MP157 SVD file is highly incomplete and plain wrong at times. Could you please update it?

NHues.1
Associate II

Hi ST!

I am working with Rust on your STM32MP157. While we have this working already, this is cumbersome as we have to figure all register addresses and layouts manually. Normally, in Rust, we parse the SVD file corresponding to a chip and go from there which is a huuuge improvement to doing everything manually. Unfortunately the SVD files available for the STM32MP157 are highly incomplete and wrong at times. Could you please fix & update the SVD files?

Thanks a lot!

Best,

Noah

1 ACCEPTED SOLUTION

Accepted Solutions
Imen Ezzine
ST Employee

I am attaching the latest fixed SVD file for STM32MP157 (version 1.6) with the fix (waiting to be integrated in tools).

Please don't hesitate if you have more feedbacks.

-Imen

View solution in original post

13 REPLIES 13
Olivier GALLIEN
ST Employee

Hi @NHues.1​ 

Can you please confirm you are talking about SDK/sysroots/x86_64-ostl_sdk-linux/usr/share/cmsis-svd/cmsis_svd/data/STMicro/STM32MP15xxx.svd file ?

Thx

Olivier

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
NHues.1
Associate II

Hi @Community member​ 

I am not sure where to find that file you mentioned. We use the tools as explained in the STM32MP1 wiki and use the yocto linux from the ST Github (btw, it is a shame that the issue system is disabled for the ST repos; makes it hard to contribute to OSS :( ).

The SVD file I tried to use is the one listed here: https://www.st.com/en/microcontrollers-microprocessors/stm32mp157.html#resource

I found another one that seems to match your given path but is broken too in here: https://raw.githubusercontent.com/mattnite/svd-data/stable/0.1/data/st-micro/STM32MP15xxx.svd

You can see that it is broken from the fact that for example the UART, TWI, SPI, etc. interrupts are completely missing. The one I just found on GH is a bit better than the one on your homepage, as it has some more interrupts listed (EXTI for example) and the UART peripherals all derive from USART1. In the one on your homepage they derive from USART2 ...

Also, you use USART in some parts of your SVDs and UART in other parts. It would be greatly appreciated if the naming was more consistent.

Thank you for your support =)

Olivier GALLIEN
ST Employee

Hi @NHues.1​ 

Issue has been escalated. Keep you posted.

Olivier

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
Imen Ezzine
ST Employee

Hi NHues.1,

At first look I can confirm that the SVD file you are using is a bit old comparing to what we have today, so obviously it can present some bugs.

Also newer SVD files have additional support for disable condition to MP1 peripherals - MCU if this feature interest you.

We just want to make sure the SVD file we have today has fixed all the points you mentioned above, if not action will be taken to fix asap.

Thank you for your feedback!

-Imen

NHues.1
Associate II

Hi @Imen Ezzine​ 

Thank you very much for looking into this.

I am not sure what disable conditions you are talking about. I am interested in a complete SVD file that describes all important peripherals, such as the UART, I2C, IPCC, ADC, etc. I am also interested in a complete set of interrupt descriptions.

I will use this SVD to generate a HAL in Rust (see https://github.com/stm32-rs/stm32-rs) to control the M4 core on the MP1. So we don't really need to disable any peripherals, but we are interested in a complete description of all the peripherals.

Sure there is some lower priority peripherals such as the MMU, but if they're available that would be great.

This seems like it could easily be autogenerated from your hardware files/specification all the same for each and every chip (your lineup is huge and has all similar peripherals, so this would spare a lot of trouble & time & cost!). Could you explain to me what the difficulty is here, maybe I am missing the obvious? 🙂

Thanks again!

Best,

Noah

Imen Ezzine
ST Employee

Hi NHues.1,

  • To start by introducing the added new feature in our latest SVD files for the STM32MP1, this need for "disable condition" was for when trying to access a not clocked register via JTAG/SWD which leads to an AXI Bus Hang. A way to avaid that is for the SFR view to use the Disable condition in CubeIDE for example. But if the need is not present for you then it shouldn't cause any problem.
  • I did verify for you and we added missing interrupts as you need for all peripherals. Also for better view and search for the peripherals they are reorder alphabetically.
  • For the USART / UART mismatch in naming, this can be explained that the SVD is based on RM (RM0436) that has UARTx name for some components and USARTx for others ==> To be consistent all naming changes to USARTx.

-Imen

Imen Ezzine
ST Employee

I am attaching the latest fixed SVD file for STM32MP157 (version 1.6) with the fix (waiting to be integrated in tools).

Please don't hesitate if you have more feedbacks.

-Imen

Maxime Borges
Associate

Hi Imen,

I'm working with NHues.1 on the HAL for the STM32MP1 chips in Rust.

Thanks for your updated SVD, it's much easier to have a full-featured SVD than making patches by hand.

At the moment I'm mainly working on the IPCC, and it seems that everything is looking good down there.

By the way, I don't know if you're following what's happening on the stm32-rs project, but a lot of people are working on making patches for the SVD of most of your microcontrollers, so if you have some resources to help this community it would definitely be very appreciated 🙂

Imen Ezzine
ST Employee

Hi Maxime Borges,

Thank you for bringing this to my attention!

We are working on providing better quality and complete SVD files with more enhancements especially for our new products. And it always helps to receive feedbacks about old products to fix possible bugs.

Don't hesitate to contact me for future possible SVD requests. And glad I could help with this one.

-Imen