Making SVD Files Searchable With Svd2db

Everyone who writes bare-metal code for microcontrollers probably know the joys of looking up the details of specific registers in the reference manual, including their absolute address. Although the search function of the PDF viewer can be helpful, it’d be rather nice if there was a way to search only the registers, and have the offset calculations performed automatically. This is basically what [Terry Porter]’s Svd2db tool enables. As the name suggests, this tool turns the SVD hardware description files that come with ARM-based MCUs into a database file.

This database file is an SQLite database, which allows it to be searched using the provided readdb tool, or any other SQLite tool. This would make the utility useful not just for quick look-ups during development, but presumably also for automated testing scenarios where having an easily searchable database of registers is of use. At this point Svd2db is guaranteed to work with STM32 SVDs, but may work with SVDs for other ARM-based SVD files as well.

 

10 thoughts on “Making SVD Files Searchable With Svd2db

  1. As rare as it is, there are still occasions to bypass the development SW and tinker with the registers. For example, I had a micropower application that varied in it’s power consumption. It was due to floating inputs that the compiler failed to acknowledge, but were on the die. The chip package we used simply had fewer pins then the die and the compiler ignored these unavailable pins.

    1. I fallen pray to errata’s and bugs by using higher level code and not poking the registers direct, examples are stm’s that some irq’s have a bit flag thats cleared and reset but that part was missed in the docs for “that chip” but present in the demos missing in the official code ,so looking at register level to find one rouge 1/0 is absolute benefit.

    1. That’s easy to answer.

      Imagine you’re building a new embedded programming language, let’s call it “tgmicro” ?
      You have built all the hard parts, the language is easy to use and you think it will be a fantastic alternative to C but only one problem remains …

      How do you tell your language, on a mcu basis, where all the peripheral registers are, what are the bitfield values and permissions ?

      A STM32F746 micro has 98 peripherals, 1778 registers and 14338 bitfields and that information has to be known by the language so it can configure and use the peripherals.

      SVD2DB allows you to easily extract this information from the micro’s SVD file.

    1. That’s not a bad idea, but a wiki page could never search all the data easily for all the mcu models. Besides, do you want to be bugged with pleas for money or the site will close ?

      Perhaps a website with a Sqlite front end and a searchable mcu index?

      SVD2DB would allow this to be fairly easily done. All that’s needed is some web entrepreneur to work out how to do it and get paid for their trouble and to cover costs.

  2. Embedded Rust on bare metal generally has a Peripheral Access Crate (or PAC) at the bottom of the stack. This is usually autogenerated from the SVD file, and helps avoid that thing in C where you accidentally set Register A using the bit mask for a field in Register B.

    Sadly many SVDs were only intended as debugging tools and are riddled with errors.

    The RP2040 one is ok though. It looks like this as Rust code: https://docs.rs/rp2040-pac/latest/rp2040_pac/

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.