cmsis-svd / cmsis-svd

Aggegration of ARM Cortex-M (and other) CMSIS SVDs and related tools

CMSIS-SVD Parsers

This repository seeks to provide value to developers targeting ARM platforms. It provides parsers that make code generation and tooling based on SVD easier to build. Most parsers simply parse a provided SVD file and turn it into a data structure more easily used in that language.

What is CMSIS-SVD

ARM provides the following description of CMSIS-SVD (System View Description)

The CMSIS System View Description format(CMSIS-SVD) formalizes the description of the system contained in ARM Cortex-M processor-based microcontrollers, in particular, the memory-mapped registers of peripherals. The detail contained in system view descriptions is comparable to the data in device reference manuals. The information ranges from high-level functional descriptions of a peripheral all the way down to the definition and purpose of an individual bit field in a memory-mapped register.

How Can the CMSIS-SVD Be Used

The generic description of each MCUs CPU and hardware registers is very valuable when generating code that can be used for talking to specific target hardware. In fact, much of the code in parts of CMSIS itself are generated based on the SVD. ARM distributes an executable that does this transformation (SVDConvert.exe).

The information can also be used for building debug tooling, test infrastructure, or whatever else.

Contributing

Please feel free to create an issue on Github and/or submit Pull Requests with proposed changes to the repository. These will be reviewed and pulled in if deemed appropriate.

License

All the code is licensed under the terms of the Apache License v2.0 (See LICENSE-APACHE).

If you encounter an issue with the content of this repository or have a question, please do not hesitate to create an issue on Github.

cmsis-svd's Issues

Duplicate array-registers in derived peripherals

Hello,

I've only just started looking at SVD files (i.e. I'm still a newbie, so apologies if I'm using the wrong terminology) but I'm seeing odd behaviour when I try parsing the example SVD provided in the official docs.

Steps to reproduce:

1. Copy & paste the example SVD file from http://www.keil.com/pack/doc/cmsis/SVD/html/svd_Example_pg.html and save it as cmsis_example.svd
2. Run the following code:

from cmsis_svd.parser import SVDParser
import pprint
parser = SVDParser.for_xml_file('cmsis_example.svd')
pprint.pprint(tuple((p.name, hex(p._base_address), list((r.name, r.address_offset) for r in p.registers)) for p in parser.get_device().peripherals))

I get the following output - note that RELEOAD[0], RELEOAD[1], RELEOAD[2] and RELEOAD[3] appear twice for TIMER1 and TIMER2 😕

(('TIMER0',
  '0x40010000',
  [('CR', 0),
   ('SR', 4),
   ('INT', 16),
   ('COUNT', 32),
   ('MATCH', 36),
   ('PRESCALE_RD', 40),
   ('PRESCALE_WR', 40),
   ('RELOAD[0]', 80),
   ('RELOAD[1]', 84),
   ('RELOAD[2]', 88),
   ('RELOAD[3]', 92)]),
 ('TIMER1',
  '0x40010100',
  [('CR', 0),
   ('SR', 4),
   ('INT', 16),
   ('COUNT', 32),
   ('MATCH', 36),
   ('PRESCALE_RD', 40),
   ('PRESCALE_WR', 40),
   ('RELOAD[0]', 80),
   ('RELOAD[1]', 84),
   ('RELOAD[2]', 88),
   ('RELOAD[3]', 92),
   ('RELOAD[0]', 80),
   ('RELOAD[1]', 84),
   ('RELOAD[2]', 88),
   ('RELOAD[3]', 92)]),
 ('TIMER2',
  '0x40010200',
  [('CR', 0),
   ('SR', 4),
   ('INT', 16),
   ('COUNT', 32),
   ('MATCH', 36),
   ('PRESCALE_RD', 40),
   ('PRESCALE_WR', 40),
   ('RELOAD[0]', 80),
   ('RELOAD[1]', 84),
   ('RELOAD[2]', 88),
   ('RELOAD[3]', 92),
   ('RELOAD[0]', 80),
   ('RELOAD[1]', 84),
   ('RELOAD[2]', 88),
   ('RELOAD[3]', 92)]))

Update Freescale/NXP files

As mentioned in #29 the acquisition of NXP changed a few things and the included SVD files are incredibly out of date. I'd be happy to provide some updates via PR but the question would be how to tackle that, i.e. do we want to get rid of the Freescale section and put the files into a new NXP folder instead?

Running examples without install

Nice little project!

Can I run the examples directly from the development directory / without installing? I tried

git/cmsis-svd/python$ python -m cmsis_svd.examples.show_k20_json

But it can't find the file:

Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/home/tdos/git/cmsis-svd/python/cmsis_svd/examples/show_k20_json.py", line 19, in <module>
    parser = SVDParser.for_packaged_svd('Freescale', 'MK20D7.xml')
  File "cmsis_svd/parser.py", line 80, in for_packaged_svd
    return cls.for_xml_file(pkg_resources.resource_filename("cmsis_svd", resource))
  File "cmsis_svd/parser.py", line 70, in for_xml_file
    return cls(ET.parse(path))
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1182, in parse
    tree.parse(source, parser)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 647, in parse
    source = open(source, "rb")
IOError: [Errno 2] No such file or directory: 'cmsis_svd/data/Freescale/MK20D7.xml'

Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/home/tdos/git/cmsis-svd/python/cmsis_svd/examples/show_k20_json.py", line 19, in <module>
    parser = SVDParser.for_packaged_svd('Freescale', 'MK20D7.xml')
  File "cmsis_svd/parser.py", line 80, in for_packaged_svd
    return cls.for_xml_file(pkg_resources.resource_filename("cmsis_svd", resource))
  File "cmsis_svd/parser.py", line 70, in for_xml_file
    return cls(ET.parse(path))
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1182, in parse
    tree.parse(source, parser)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 647, in parse
    source = open(source, "rb")
IOError: [Errno 2] No such file or directory: 'cmsis_svd/data/Freescale/MK20D7.xml'

No LPC15xx. Can I help?

I see there is no file for the LPC15xx, is there a ways I can help find/generate one?

Vendors use enumeratedValues in odd ways

http://www.keil.com/pack/doc/CMSIS/SVD/html/group__svd__xml__enum__gr.html states that enumeratedValues::enumeratedValue::value "Defines the constant of the bit-field that the name corresponds to.", however some svd files like https://raw.githubusercontent.com/posborne/cmsis-svd/master/data/Freescale/MKL27Z4.svd define enumerated values like this:

<register>
          <name>PDDR</name>
          <description>Port Data Direction Register</description>
          <addressOffset>0x14</addressOffset>
          <size>32</size>
          <access>read-write</access>
          <resetValue>0</resetValue>
          <resetMask>0xFFFFFFFF</resetMask>
          <fields>
            <field>
              <name>PDD</name>
              <description>Port Data Direction</description>
              <bitOffset>0</bitOffset>
              <bitWidth>32</bitWidth>
              <access>read-write</access>
              <enumeratedValues>
                <enumeratedValue>
                  <name>0</name>
                  <description>Pin is configured as general-purpose input, for the GPIO function.</description>
                  <value>#0</value>
                </enumeratedValue>
                <enumeratedValue>
                  <name>1</name>
                  <description>Pin is configured as general-purpose output, for the GPIO function.</description>
                  <value>#1</value>
                </enumeratedValue>
              </enumeratedValues>
            </field>
          </fields>
        </register>

Its a 32 bit wide field with two possible values... I understand what they mean, you pick the right enum value and then shift it, really they should have defined 32 one bit wide fields instead.

Any way even though I understand what they mean my code doesn't and since Kvasir has super static checking it squawks at me that the value I'm wirting into the register is not the same type as the enum.

Do we agree that this is a misinterpretation of the CMSIS-SVD on the part of freescale or should I be making my script smarter?

As a work around I'm disabling the generation of enums if they are narrower than the field and have no default, but thats beside the point.

parsing blob files, possible with this lib?

Hello. Dealing with some hisilicon chips. they generally initalize a number of registers using a sort of binary
csv file with the following format:

struct regentry {
    uint32_t reg_addr; // address of the register
    uint32_t value; // value to be written or read
    uint32_t delay; // amount of nop's to execute to delay
    uint32_t attr; // read or write and other flags
};

I've been putting together a svd file for the soc for use with the PyCortexMDebug project, and was hoping
this may allow for me to use said svd file to parse out the actions taken instead of manually figuring the bitfields.

for reference:

00000000  80 00 01 12 00 00 00 00  00 00 00 00 fd 00 00 00  |................|
00000010  e0 01 01 12 00 00 00 00  00 00 00 00 00 00 55 00  |..............U.|
00000020  00 00 00 00 00 00 00 00  64 00 00 00 00 00 00 00  |........d.......|
00000030  10 00 01 12 55 55 d5 12  00 00 00 00 fd 00 00 00  |....UU..........|
00000040  14 00 01 12 2d 10 00 00  00 00 00 00 fd 00 00 00  |....-...........|
00000050  00 00 00 00 00 00 00 00  64 00 00 00 00 00 00 00  |........d.......|
00000060  e8 01 01 12 0f 00 00 00  00 00 00 00 00 00 1d 00  |................|
00000070  80 00 01 12 9b 05 00 00  00 00 00 00 fd 00 00 00  |................|
00000080  e0 01 01 12 9b 05 00 00  00 00 00 00 00 00 55 00  |..............U.|
00000090  00 00 00 00 00 00 00 00  64 00 00 00 00 00 00 00  |........d.......|

Note these values are encoded in little endian.

do I misuse this package?

After tring the latest version(Feb 17, 2019), I get the following two errors. Do I access them correctly?

Thank you:-)

Microsoft Windows [版本 6.0.6001]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.

D:\Works\Python\cmsis-svd-master\python>py
Python 3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 19:28:18) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.

import cmsis_svd
from cmsis_svd.parser import SVDParser
parser = SVDParser.for_packaged_svd('Atmel', 'ATSAMV71J19B.svd')
for peripheral in parser.get_device().peripherals:
... for reg in peripheral.registers:
... print(reg.name, reg.address_offset)
...
ACC_CR 0
ACC_MR 4
ACC_IER 36
ACC_IDR 40
ACC_IMR 44
ACC_ISR 48
ACC_ACR 148
ACC_WPMR 228
ACC_WPSR 232
ACC_VER 252
Traceback (most recent call last):
File "", line 2, in
File "D:\Works\Python\cmsis-svd-master\python\cmsis_svd\model.py", line 505, in registers
regs.extend(arr.registers)
File "D:\Works\Python\cmsis-svd-master\python\cmsis_svd\model.py", line 207, in registers
name=self.name % self.dim_indices[i],
TypeError: not all arguments converted during string formatting

For device ('NXP', 'LPC178x_7x.svd'), there is another type of error:
...
...
RXBITRATE 44
TXMODE 48
RXMODE 52
Traceback (most recent call last):
File "", line 2, in
File "D:\Works\Python\cmsis-svd-master\python\cmsis_svd\model.py", line 502, in registers
for reg in self._lookup_possibly_derived_attribute('registers'):
TypeError: 'NoneType' object is not iterable

remove_reserved does the opposite of what it says

In the call to SVDParser.for_packaged_svd(), remove_reserved=False causes reserved register fields to be removed and remove_reserved=True causes them to be kept. From the naming, I would have expected the opposite behavior.

I believe, the following code in _parse_registers() is to blame:

if self.remove_reserved or 'reserved' not in node.name.lower():
    fields.append(node)

This should probably be:

if not self.remove_reserved or 'reserved' not in node.name.lower():
    fields.append(node)

AT91SAM9G10 fails because peripheral UHP does not have any registers

adding an if here https://github.com/posborne/cmsis-svd/blob/master/python/cmsis_svd/model.py#L340 fixes this but I'm not sure if this is the right solution. My python skills have been known to suck miserably.

Q: Are none ARM-Cortex PR's with svd's welcome?

The title says it all.

I have some AVR ATMega svd files, converted from asdf, and some TI MSP 430 svd files also converted.

Is this repo abandoned?

It's been four months since last commit to this repository and the queue of PRs is now quite long. People decided to rely on this as source of truth regarding SVDs, but in the context of that delay it seems it was bad decision.

Any chances to get these picked up soon? If not maybe consider transfer responsibility into some other hands, I suggest create organisation with a few seriously interested parties as maintainers.

Thank you.

Compile SVD to binary for packaging

Given that there is an XML schema for the SVD files, it might be an idea to use this information to avoid redundancy when encoding SVD files for the release.

As far as I could see in the source of this repo, the parser currently mostly tries to map the plain XML into the components according to the schema definition. As there's no need to load this structure from the XML file itself, any equivalent format that can be transformed back into this tree structure from the XML files should do.

Thus instead of releasing a package with all the 5.4GiB (which BTW compresses nicely down to ~114M with bzip2), one could replace the various tags from the schema with short binary sequences and thus safe on storage that way. Going further one could even go as far as compressing multiple files together and only storing differences between the various chips compared to some base file.

One option for the encoding may be Protobuf, another one would be EBML (cf. RFC 8794). Given how structured the data usually is, even writing a small streaming reader/writer with a proprietary format could be a viable option.

SVD for TI CC3200

As mentioned I am searching a svd for this processor.
Beside that, is there a nice editor which I may use to create a svd file?

Some Vendor Directories Missing License Files

The following directories do not appear to have license files at present. These should be hunted down and added or extracted from the license in individuals SVDs:

• Spansion
• Holtek
• NXP
• Nordic
• Nuvoton
• Silicon Labs
• Toshiba

Most of these seem to define a license in the individual SVDs that is consistent for the vendor. I will audit and remove any SVDs that do not include license information.

consider breaking apart parser and data packages

Hi, thank you for the great package!

One suggestion I have is to consider breaking apart the package into SVD parser and a separate data package. I'm currently using just the parser for a project, but this causes me to pull in 823MB of data that I don't use.

Thank you! :)

No support for dimElementGroups

the parser does not seem to support dimElementGroups as explained here http://www.keil.com/pack/doc/CMSIS/SVD/html/group__dim_element_group__gr.html

can you make a version 1.1 so pip install is easier?

this repo has changed a lot since version one, some people interested in developing Kvasir have been complaining that installing this dependency is too complicated (pip installing from a git hub repo took me a bit of time to figure out myself). Could we make a version 1.1?

LPC11xx_v6.svd has multiple enumerated values with the same name

So far we have been correcting names of things in extention files in order to not mess with the SVD (in order to stay open to drop in improvements from the vender), however since the extention files index things by name ambiguities are impossible to correct.

The offending tag is <name>COUNTER_MODE_TC_IS_</name> which occurs three times in the CTM field of the CTCR register all with different values.

What should we do to fix this?

Request SVD file

Request to add SVD file of RV32M1

SVDParser._parse_peripheral() should handle clusters

Peripherals defined in some SVDs (for example, the SAADC peripheral in https://github.com/posborne/cmsis-svd/blob/master/data/Nordic/nrf52.svd) declare some registers via clusters.

However, the current SVDParser._parse_peripheral() implementation in parser.py (i.e. https://github.com/posborne/cmsis-svd/blob/master/python/cmsis_svd/parser.py#L240) does not take this into account. This means that the parsed peripheral's register list is missing information that is provided in the SVD file.

Here is an example of clusters as used by the SAADC peripheral definition for nRF52:

<peripheral>
  <name>SAADC</name>
  <description>Analog to Digital Converter</description>
  <!-- [snip] -->
  <registers>
    <register>
      <name>TASKS_START</name>
      <!-- [snip] -->
    </register>
    <register>
      <name>TASKS_SAMPLE</name>
      <!-- [snip] -->
    </register>
    <!-- [snip] -->
    <cluster>
      <name>RESULT</name>
      <description>RESULT EasyDMA channel</description>
      <headerStructName>SAADC_RESULT</headerStructName>
      <addressOffset>0x62C</addressOffset>
      <register>
	<name>PTR</name>
	<description>Data pointer</description>
	<addressOffset>0x000</addressOffset>
	<access>read-write</access>
	<fields>
	  <field>
	    <name>PTR</name>
	    <description>Data pointer</description>
	    <lsb>0</lsb>
	    <msb>31</msb>
	  </field>
	</fields>
      </register>
      <register>
	<name>MAXCNT</name>
	<description>Maximum number of buffer words to transfer</description>
	<addressOffset>0x004</addressOffset>
	<access>read-write</access>
	<fields>
	  <field>
	    <name>MAXCNT</name>
	    <description>Maximum number of buffer words to transfer</description>
	    <lsb>0</lsb>
	    <msb>15</msb>
	  </field>
	</fields>
      </register>
      <register>
	<name>AMOUNT</name>
	<description>Number of buffer words transferred since last START</description>
	<addressOffset>0x008</addressOffset>
	<access>read-only</access>
	<fields>
	  <field>
	    <name>AMOUNT</name>
	    <description>Number of buffer words transferred since last START. This register can be read after an END or STOPPED event.</description>
	    <lsb>0</lsb>
	    <msb>15</msb>
	  </field>
	</fields>
      </register>
    </cluster>
  </registers>
</peripheral>

Note that the "clusters" node has a top-level address offset, and that the individual registers within a cluster have offsets relative to that top-level offset. Otherwise the register fields within a cluster are very similar to the register nodes already parsed (they contain name, description, addressOffset, access, and perhaps fields.

Can _parse_peripheral() be extended to support clusters as well?

Arm Development Studio sw/debugger/configdb

@jevega came up with a way to transform the Arm Development Studio configdb to clean svd. Worth a look.

https://github.com/Jegeva/ads2svd
ARM-software/CMSIS_5#844

NXP/MIMXRT1062.svd: Duplicate enumeration identifiers/names for different values

Issue

Several enumeratedValue items have duplicated name fields – albeit different enumerated value – in NXP/MIMXRT1062.svd (which is the same MCU used on the popular PJRC Teensy 4.0/4.1 boards).

Recommend updating the names to use a conventional index suffix similar to other enumeratedValue fields in this same SVD.

Use case

Any naive API generator using this SVD as source will produce ambiguous, if not illegal, enumerated value definitions.

ARM Core Registers

As also stated here, in ST svd files the memory mapped peripherals in the ARM Core are missing in the SVD files.

I have checked back on my support request with ST regarding the missing core registers.
Their statement is, that they dont want to integrate it into their svd files.

would it make sense to add Core-Only SVD files to this repo?

cmsis-svd crashing on getting derived registers

Hello,

on :
LPC178x_7x svd
LPC178x_7x_v0.8 svd
LPC408x_7x_v0.7.svd
files that are included in the data ,
it crashes on trying to iterate on the registers,

More specifically it crashes on this element of the SVDs :

<peripheral derivedFrom="SSP0"> <name>SSP2</name> <baseAddress>0x400AC000</baseAddress> <interrupt> <name>SSP2</name> <value>36</value> </interrupt> </peripheral>

here is the TB
Traceback (most recent call last):
File "./idarm-make-regtag.py", line 241, in
data = get_data_for(args.vendor, args.chip ,args.max_segment_sz_int,args,1)
File "./idarm-make-regtag.py", line 99, in get_data_for
regs = peripheral.registers
File "./cmsis-svd/python/cmsis_svd/model.py", line 502, in registers
for reg in self._lookup_possibly_derived_attribute('registers'):
TypeError: 'NoneType' object is not iterable

---

digging deeper, i saw that SSP0 is derived from SSP1. changing the peripheral SSP2 is derived from to SSP1 fixes the crash which leads me to think that cmsis-svd isn't handling the daisy chaining of derivedFrom case correctly (and i don't know if this is even legal to start with but that is in the base data package and looking at http://www.keil.com/pack/doc/CMSIS/SVD/html/schema_1_2_gr.html i don't see why you couldn't chain derived elements)

Find SVD file by MCU model name

I think in some cases developer don't know which SVD file is needed for specified MCU. He can store some matching table (mcu -> vendor, filename), but there is exists better solution. Something like this:

def find_for_mcu(mcu):
    mcu = mcu.lower()
    vendors = resource_listdir("cmsis_svd", "data")
    for vendor in vendors:
        fnames = resource_listdir("cmsis_svd", "data/%s" % vendor)
        for fname in fnames:
            filename = fname.lower()
            if not filename.endswith(".svd"):
                continue
            filename = filename[:-4]
            if mcu.startswith(filename):
                return vendor, fname
        for fname in fnames:
            filename = fname.lower()
            if not filename.endswith(".svd"):
                continue
            filename = "^%s.*" % filename[:-4].replace('x', '.')
            if re.match(filename, mcu):
                return vendor, fname
    return None, None

Some vendors use "X" character in SVD file name as "any character" pattern.
My code can find suitable SVD file by MCU model name (e. g. STM32F103C8T6), but I access to internal structures of package cmsis-svd and this is not good (you can change file layout in future).
I suggest add some function like this to your package. For example, add constructor SVDParser.from_mcu_name in addition to SVD.for_packaged_svd.
I can create pull request if you will accept this change. Or maybe you know better algorithm to translate MCU name to pair vendor:filename.

svd files do not have enough info

The bit fields of a Register can have odd behavior. An example is a bit acting as a hardware flag where the hardware can set it and the software can clear it either by reading it, writing a 1 or in some rare cases writing a 0. Another example is a bitfield acting as the end of a fifo.

This data is however highly relevant if we are going to get serious about generating any kind of validation mechanisms from the files.

Should we add tags to the svd files or define a svd enhancement format or something?
How responsive is ARM going to be about extending the format?
@0xc0170 what do you think?

Inconsistant bitfield syntax bitRange vs. bitOffset and bitWidth

Some files like https://github.com/posborne/cmsis-svd/blob/master/data/NXP/LPC11Uxx_v7.svd#L82 use <bitRange>[high:low]<bitRange> while others like https://github.com/posborne/cmsis-svd/blob/master/data/STMicro/STM32F030.svd#L60 use <bitOffset>0</bitOffset> <bitWidth>8</bitWidth>

It looks like the current parser only supports bitOffset and bitWidth, or this may be a false diagnosis due to my python skills still sucking.

Bad copy/paste in parser.py ?

I believe there is a bad copy/paste in parser.py : 'vendorSystickConfig' is used 3 times.
https://github.com/posborne/cmsis-svd/blob/15b462f152af86f3d15b952e1a5cf1bb9e2693e8/python/cmsis_svd/parser.py#L516

is this the place to maintain SVD files?

Hi,

I'm working with embsysregview and have edited some svd files.
is this the most popular place to "upstream" such changes?

best reagards

stm32f4 is out of date (at least stm32f429)

ST has version 1.2 posted: http://www.st.com/resource/en/svd/stm32f4_svd.zip

These change the names of (some?) of the processors to remove the trailing x.

For example, stm32f429x (current name) becomes stm32f429 (in 1.2).

Proposition to refactor this project into a collection of CMSIS related tools for Python

I would propose to start a new project to provide a collection of CMSIS related tools for Python. For example, the project name could be pycmsis and for the beginning it could include:

• CMSIS-SVD file parser
• "Peripheral header file" generator for different languages from vendor CMSIS-SVD files
  • Would use my yasha code generator. There's already a template for Rust and related Jinja2 filters.
• CMSIS-SVD vendor files
  • SVD file collection like in this repository, but the files would be within a separate project. So if someone just wants to use the CMSIS-SVD parser and is not interested in to have all the vendor SVD files installed too it would be handy if it can be chosen. Installation of the current project take quite a lot of time just because of all the included SVD files.
  • require_extras can be used in setup.py.
• CMSIS-DAP
  • Installs pyOCD

Finally, I would like to change the parser. Don't get me wrong. I don't mean to be rude or sound bold, but I think that the parser I have implemented is more elegant and easier to work with.

What do you think?

STMicro Content.txt out of date

Content.txt list of .svd files does not match the list of files in the repository (both missing files and extra files).

NXP seems to like naming bitfields "RESERVED"

here https://github.com/posborne/cmsis-svd/blob/9f2ca607848e5b368f89e0888a0e13c7b43cf764/data/NXP/LPC15xx_v0.7.svd for example there are many registers which contain a bitfields named RESERVED. These need to be discared (especially if two RESERVED fields occure in one register) somewhere in the chain of processing. Where would it be best to do it?

In my opinion its NXP's error so they should fix it but thats probably not going to happen so should we filter them out while parsing or should I do it in my Kvasir specific parser?

How to deal with double tags?

In MKL25Z4.swd:

  <cpu>
    <name>CM0PLUS</name>
    <revision>r0p0</revision>
    <endian>little</endian>
    <mpuPresent>false</mpuPresent>
    <fpuPresent>false</fpuPresent>
    <mpuPresent>false</mpuPresent>
    <vtorPresent>true</vtorPresent>
    <nvicPrioBits>2</nvicPrioBits>
    <vendorSystickConfig>false</vendorSystickConfig>
  </cpu>

mpuPresent is defined twice, how should we handle stuff like this generally? Here we can ignore it because they are the same, what if they were different?

Please make a new release in PyPI.

Over the last six years, many new SVD files have been added that are not included in the currently available release.

STMF301.svd is very wrong.

(Possible duplicate of #27)

The register definitions are very different from the 'F301 datasheet to the SVD.

This is an upstream issue, but my contact with STMicro doesn't fill me with hope that the issue will be fixed. I checked and they are still serving the same file as this repo.

I suspect they are from a different chip altogether.

|    Address | STM32F301.svd peripheral    | compared to datasheet  |
|------------+-----------------------------+------------------------|
| 0x40000000 | STM32F301.TIM2              | ok                     |
| 0x40000400 | STM32F301.TIM3              | missing from datasheet |
| 0x40000800 | STM32F301.TIM4              | missing from datasheet |
| 0x40000c00 | STM32F301.TIM5              | missing from datasheet |
| 0x40001000 | STM32F301.TIM6              | ok                     |
| 0x40001400 | STM32F301.TIM7              | missing from datasheet |
| 0x40001800 | STM32F301.TIM12             | missing from datasheet |
| 0x40001c00 | STM32F301.TIM13             | missing from datasheet |
| 0x40002000 | STM32F301.TIM14             | missing from datasheet |
| 0x40002800 | STM32F301.RTC               | ok                     |
| 0x40002c00 | STM32F301.WWDG              | ok                     |
| 0x40003000 | STM32F301.IWDG              | ok                     |
| 0x40003400 | STM32F301.I2S2ext           | ok                     |
| 0x40003800 | STM32F301.SPI2              | ok                     |
| 0x40003c00 | STM32F301.SPI3              | ok                     |
| 0x40004000 | STM32F301.I2S3ext           | ok                     |
| 0x40004400 | STM32F301.USART2            | ok                     |
| 0x40004800 | STM32F301.USART3            | ok                     |
| 0x40005400 | STM32F301.I2C1              | ok                     |
| 0x40005800 | STM32F301.I2C2              | ok                     |
| 0x40005c00 | STM32F301.USB               | missing from datasheet |
| 0x40006400 | STM32F301.CAN               | missing from datasheet |
| 0x40007000 | STM32F301.PWR               | ok                     |
| 0x40007400 | STM32F301.DAC1              | ok                     |
| 0x40007800 | STM32F301.CEC               | missing from datasheet |
| 0x40007800 |                             | I2C3 missing from SVD  |
| 0x40009800 | STM32F301.DAC2              | missing from datasheet |
| 0x40009c00 | STM32F301.TIM18             | missing from datasheet |
| 0x40010000 | STM32F301.SYSCFG_COMP_OPAMP | ok                     |
| 0x40010400 | STM32F301.EXTI              | ok                     |
| 0x40012c00 |                             | TIM1 missing from SVD  |
| 0x40013000 | STM32F301.SPI1              | missing from datasheet |
| 0x40013800 | STM32F301.USART1            | ok                     |
| 0x40014000 | STM32F301.TIM15             | ok                     |
| 0x40014400 | STM32F301.TIM16             | ok                     |
| 0x40014800 | STM32F301.TIM17             | ok                     |
| 0x40015c00 | STM32F301.TIM19             | missing from datasheet |
| 0x40016000 | STM32F301.SDADC1            | missing from datasheet |
| 0x40016400 | STM32F301.SDADC2            | missing from datasheet |
| 0x40016800 | STM32F301.SDADC3            | missing from datasheet |
| 0x40020000 | STM32F301.DMA1              | ok                     |
| 0x40020400 | STM32F301.DMA2              | missing from datasheet |
| 0x40021000 | STM32F301.RCC               | ok                     |
| 0x40022000 | STM32F301.Flash             | ok                     |
| 0x40023000 | STM32F301.CRC               | ok                     |
| 0x40024000 | STM32F301.TSC               | ok                     |
| 0x48000000 | STM32F301.GPIOA             | ok                     |
| 0x48000400 | STM32F301.GPIOB             | ok                     |
| 0x48000800 | STM32F301.GPIOC             | ok                     |
| 0x48000c00 | STM32F301.GPIOD             | ok                     |
| 0x48001000 | STM32F301.GPIOE             | missing from datasheet |
| 0x48001400 | STM32F301.GPIOF             | ok                     |
| 0x50000000 | STM32F301.ADC               | ok                     |

CC26X0 svd file request

CC26X0 (as well as CC26X0R2F) is a series of Cortex-M3 MCU with built-in RF support. It is a new series though, it would be very useful if there is a SVD file here in this project.
(As far as I know, TI does not offer this kind of file officially, but maybe we can convert from device database from TI's IDEs.)

Push a new version to https://pypi.org/project/cmsis-svd/

The last release on PyPI was in 2016.

stm32 is out of date

Every one stm32 devices have update svd science november 2017, but in your repository svd date for many chips is older than it. Please update stm32 devices.

Thanks.

SVD clusters should be used for register groupings

Currently, in Freescale Kinetis SVD files (such as https://github.com/posborne/cmsis-svd/blob/master/data/Freescale/MKL25Z4.svd), what logically is an array of a grouping of registers is being represented in the SVD file as separate "dim" arrays of registers. For example:

        <register>
          <dim>6</dim>
          <dimIncrement>0x8</dimIncrement>
          <dimIndex>0,1,2,3,4,5</dimIndex>
          <name>C%sSC</name>
          <description>Channel (n) Status and Control</description>
          **<addressOffset>0xC</addressOffset>**
          <size>32</size>
          <access>read-write</access>
          <resetValue>0</resetValue>
          <resetMask>0xFFFFFFFF</resetMask>
          <fields>
            ...
          </fields>
        </register>
        <register>
          <dim>6</dim>
          <dimIncrement>0x8</dimIncrement>
          <dimIndex>0,1,2,3,4,5</dimIndex>
          <name>C%sV</name>
          <description>Channel (n) Value</description>
          **<addressOffset>0x10</addressOffset>**
          <size>32</size>
          <access>read-write</access>
          <resetValue>0</resetValue>
          <resetMask>0xFFFFFFFF</resetMask>
          <fields>
          ...
          </fields>
        </register>

This does not take advantage of the cluster construct in SVD syntax, which would be
both more readable and would allow tools like SVDConv generate code that is easier to work with. For the example above, the code generated by the ARM SVDConv tool looks like this:

typedef struct {                                    /*!< TPM0 Structure                                                        */
     ...
     __IO uint32_t  C0SC;                              /*!< Channel (n) Status and Control                                        */
     __IO uint32_t  C0V;                               /*!< Channel (n) Value                                                     */
     __IO uint32_t  C1SC;                              /*!< Channel (n) Status and Control                                        */
     __IO uint32_t  C1V;                               /*!< Channel (n) Value                                                     */
     __IO uint32_t  C2SC;                              /*!< Channel (n) Status and Control                                        */
     __IO uint32_t  C2V;                               /*!< Channel (n) Value                                                     */
     __IO uint32_t  C3SC;                              /*!< Channel (n) Status and Control                                        */
     __IO uint32_t  C3V;                               /*!< Channel (n) Value                                                     */
     __IO uint32_t  C4SC;                              /*!< Channel (n) Status and Control                                        */
     __IO uint32_t  C4V;                               /*!< Channel (n) Value                                                     */
     __IO uint32_t  C5SC;                              /*!< Channel (n) Status and Control                                        */
     __IO uint32_t  C5V;                               /*!< Channel (n) Value                                                     */
     ...
} TPM0_Type;`

In contrast, if we rewrite the SVD fragment shown above, using a * cluster*, as shown below:

        <cluster>
            <dim>6</dim>
            <dimIncrement>8</dimIncrement>
            <dimIndex>0-5</dimIndex>
            <name>CHANNELS[%s]</name>
            <description>Grouping of Channels</description>
            <addressOffset>0xC</addressOffset>
            <register>
              <name>CnSC</name>
              <description>Channel (n) Status and Control</description>
              <addressOffset>0x0</addressOffset>
              <size>32</size>
              <access>read-write</access>
              <resetValue>0</resetValue>
              <resetMask>0xFFFFFFFF</resetMask>
              <fields>
               ...
              </fields>
            </register>
            <register>
              <name>CnV</name>
              <description>Channel (n) Value</description>
              <addressOffset>0x4</addressOffset>
              <size>32</size>
              <access>read-write</access>
              <resetValue>0</resetValue>
              <resetMask>0xFFFFFFFF</resetMask>
              <fields>
              ...
              </fields>
            </register>
        </cluster>

the corresponding C code generated by the ARM SVDConv tool would look like this:

typedef struct {
  __IO uint32_t  CnSC;                              /*!< Channel (n) Status and Control                                        */
  __IO uint32_t  CnV;                               /*!< Channel (n) Value                                                     */
} TPM0_CHANNELS_Type;

typedef struct {                                    /*!< TPM0 Structure                                                        */
  ...
  TPM0_CHANNELS_Type CHANNELS[6];                   /*!< Grouping of Channels                                                  */
  ...
} TPM0_Type;

which is both more readable and easier to work with in code that uses it.
So, All the Freescale Kinetis SVD files should be updated to use clusters where
appropriate.

Displaying a 64 bit register

I want to check out the NVM User Row register of the SAMD21 via svd. Since it's not defined in ATSAMD21G18A.svd I tried to add it myself.

The problem is, I can only see the values that are in the first word. This register is split into two words: 0x804000 and 0x804004.

From the SAMD21 datasheet:

Here is what I added to the svd file:

      <name>NVM</name>
      <description>NVM</description>
      <baseAddress>0x804000</baseAddress>
      <registers>
        <register>
          <name>USER_ROW</name>
          <description>user row 0x804000</description>
          <addressOffset>0x0</addressOffset>
          <size>0x40</size>
          <fields>
            <field>
              <name>BOOTPROT</name>
              <bitRange>[2:0]</bitRange>
            </field>
            <field>
              <name>EEPROM</name>
              <bitRange>[6:4]</bitRange>
            </field>
            <field>
              <name>BOD33 Level</name>
              <bitRange>[13:8]</bitRange>
            </field>
            <field>
              <name>BOD33 Enable</name>
              <bitRange>[14:14]</bitRange>
            </field>
            <field>
              <name>BOD33 Action</name>
              <bitRange>[16:15]</bitRange>
            </field>
            <field>
              <name>WDT Enable</name>
              <bitRange>[25:25]</bitRange>
            </field>
            <field>
              <name>WDT Always-On</name>
              <bitRange>[26:26]</bitRange>
            </field>
            <field>
              <name>WDT Period</name>
              <bitRange>[30:27]</bitRange>
            </field>
            <field>
              <name>WDT Window</name>
              <bitRange>[34:31]</bitRange>
            </field>
            <field>
              <name>WDT EWOFFSET</name>
              <bitRange>[38:35]</bitRange>
            </field>
            <field>
              <name>WDT WEN</name>
              <bitRange>[39:39]</bitRange>
            </field>
            <field>
              <name>BOD33 Hysteresis</name>
              <bitRange>[40:40]</bitRange>
            </field>
            <field>
              <name>LOCK</name>
              <bitRange>[63:48]</bitRange>
            </field>
          </fields>
        </register>
      </registers>
    </peripheral>

The second word seems to be missing:

(gdb) x/t 0x804000
0x804000:	11011000111000000000000000000111
(gdb) 
0x804004:	11111111111111111111110001011101
(gdb) svd/t NVM 
Registers in NVM:
	USER_ROW:  0b0000000000000000000000000000000011011000111000000000000000000111  user row 0x804000
(gdb) svd/d NVM USER_ROW
Fields in NVM USER_ROW:
	BOOTPROT:           7  
	EEPROM:             0  
	BOD33 Level:        0  
	BOD33 Enable:       0  
	BOD33 Action:       0  
	WDT Enable:         0  
	WDT Always-On:      0  
	WDT Period:        11  
	WDT Window:         1  
	WDT EWOFFSET:       0  
	WDT WEN:            0  
	BOD33 Hysteresis:   0  
	LOCK:               0  

I haven't tried the .svd file in other software.

No support for inheriting tags

Tags like derivedFrom or size etc. affect children further down the tree. In order to implement support for them we need to either do a second pass through the parsed tree and fill in the default values when possible or make the tree which has been parsed so far availible to the _parse_x(self, x_node) node functions to allow them to extract defaults from further up the tree.

As I understand so far it is more pythonical to do just one pass, should I do it that way?

Freescale SVD files update

Hi,

it seems like Freescale (NXP) is distributing their most recent svd files for the kinetis family of controllers bundled in their Kinetis Design Studio (KDS).

Freescale seems to refuse the "official" SVD distribution through the SVD section on the ARM CMSIS webpage

The files coming with the KDS contain extended description of peripherals and also the ARM Core Registers like NVIC and SCB.

I have created a repository to easily compare them.
is it worth a merge / update ?

some files are gone. why?

@flit maybe i should mention you here ;)

Adding support for Gigadevice's GD32VF103 chip (Sipeed's Longan Nano board)

Hi.
I am curious about what blocks the usage of the following SVD file:
https://raw.githubusercontent.com/sipeed/platform-gd32v/master/misc/svd/GD32VF103.svd
.

A part of campaign for supporting https://longan.sipeed.com/en/ , for TinyGo project

Deriving of peripheral attributes is not working correctly

The attributes size, access, protection, reset_value, reset_mask are not derived correctly.

Example:

from cmsis_svd.parser import SVDParser

parser = SVDParser.for_packaged_svd("ARM_SAMPLE", "ARM_Sample.svd")

for peripheral in parser.get_device().peripherals:
    print(f"Peripheral name: {peripheral.name}, Reset mask: {peripheral.reset_mask}")

Output:

Peripheral name: TIMER0, Reset mask: 4294967295
Peripheral name: TIMER1, Reset mask: None
Peripheral name: TIMER2, Reset mask: None

Expected output:

Peripheral name: TIMER0, Reset mask: 4294967295
Peripheral name: TIMER1, Reset mask: 4294967295
Peripheral name: TIMER2, Reset mask: 4294967295

Some of the STMicro SVDs are named .svd

https://github.com/posborne/cmsis-svd/tree/master/data/STMicro some of the STMicro SVDs are named .svd, all other files are names *.xml, is there a reason for the .svd ending rather than xml or should I change them all?

Installation failure with some versions of pip

I'm seeing an installation failure when installing cmsis-svd version 0.2 or 0.3. Version 0.1 installs without problems. This can be reproduced with the following script:

virtualenv env
env\Scripts\activate
pip install pip==7.1.2
pip install cmsis-svd==0.3 --no-cache

Related issue pyocd/pyOCD#251

Inheritance not fully defined

I'm having trouble interpreting effects of the derivedFrom tag. It is not clear to what granularity tags in the derived ovject override tags in the base object. For example here http://www.keil.com/pack/doc/CMSIS/SVD/html/group__svd__xml__peripherals__gr.html the peripheral "Timer0" has one interrupt called "TIM0_INT", "timer1" derived from "timer0" which begs the questions:

• Does "timer1" have no interrupts?
• Does "timer1" share an interrupt with "timer0"? If so why is it called "TIM0_INT"?

SAM{E,V,S}7X SVDs are outdated

After a chat with Microchip it was pointed out that http://packs.download.atmel.com/ is outdated. The up-to-date pack repository is https://packs.download.microchip.com/, where much more recent SVD files for the SAM{E,V,S}7X chips can be found: the latest version for the SAME70 is 4.8.125 (from 2022), versus 2.4.166 (from 2019) mirrored in this repo.

An SVD issue regarding USART-SPI clock sources has also been filed recently; a bug-fix release is expected soon.

I have not checked if updates are available for other chip families.

Parser missing IRQs (CMSDK_CM3.svd)

While parsing ARM CMSDK_CM3.svd extracted from Keil.V2M-MPS2_CMx_BSP.1.7.0.pack it appears the second IRQs for all peripherals are missing. Everything looks fine when I examine the SVD file manually. This device is of special importance as its available in QEMU. Any assistance would be appreciated as my python skills are poor.