| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| <html xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml"><head> |
| |
| <title>CMSIS - SVD: Cortex Microcontroller Software Interface Standard - System View Description</title><meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> |
| <meta name="ProgId" content="FrontPage.Editor.Document"> |
| <style type="text"> |
| |
| |
| |
| </style> |
| <style type="text/css"> |
| .style1 { |
| text-align: center; |
| } |
| .style2 { |
| font-weight: normal; |
| } |
| .style3 { |
| text-align: left; |
| } |
| .style4 { |
| color: #008000; |
| } |
| .style5 { |
| color: #0000FF; |
| } |
| .style6 { |
| color: #000000; |
| } |
| </style> |
| </head> |
| |
| <body> |
| <h1 class="style1">Cortex Microcontroller Software Interface Standard<br> |
| System View Description</h1> |
| |
| <p class="style1">This file describes the Cortex Microcontroller Software |
| Interface Standard - System View Description (CMSIS - SVD) concept and syntax.</p> |
| <p class="style1">Version: 1.02 - 27. July 2011</p> |
| |
| <p class="style1">Information in this file, the accompany manuals, and software is<br> |
| Copyright © ARM Ltd.<br>All rights reserved. |
| </p> |
| |
| <hr> |
| |
| <p><span style="FONT-WEIGHT: bold">Revision History</span></p> |
| <ul> |
| <li>Version 0.91: initial proposal.</li> |
| <li>Version 0.92: revised proposal considering forum feedback (e.g. consider |
| IP-XACT constructs and naming scheme)</li> |
| <li>Version 1.0: new elements: peripheral version, vendor specific |
| extension section, interrupt mapping information, global peripheral disable |
| condition, naming of register arrays, enhanced naming schemes, etc.</li> |
| <li>Version 1.0: SVD versioning and updated schema file</li> |
| <li>Version 1.01: Error corrections in the example code. "include" has been removed. Restricted to one device per file.</li> |
| <li>Version 1.02: Adding the use case of device header file generation.</li> |
| </ul> |
| |
| <p> </p> |
| |
| <hr> |
| |
| <h2>Contents</h2> |
| |
| <ol> |
| <li class="LI2"><a href="#1">About</a></li> |
| <li class="LI2"><a href="#2">Motivation</a></li> |
| <li class="LI2"><a href="#3">Requirements</a></li> |
| <li class="LI2"><a href="#4">Format</a></li> |
| <li class="LI2"><a href="#5">Example</a></li> |
| <li class="LI2"><a href="#6">Questions & Answers</a></li> |
| </ol> |
| |
| <h2><a name="1"></a>About</h2> |
| |
| <p> |
| The <strong>Cortex Microcontroller Software Interface Standard - System View |
| Description</strong> (CMSIS - SVD) answers the challenges |
| of accurate, detailed and timely device aware peripheral debugging support for Cortex |
| Microcontroller based devices by the software development |
| tools vendor community. |
| </p> |
| <p> |
| Silicon vendors shall create and maintain a formalized description of the |
| debug view for all the peripherals contained in their Cortex |
| Microcontroller based devices. Tool vendors use such descriptions to |
| establish device specific debug support in their debugging tools with minimal turn around times and |
| manageable effort. Device support across many development tools is |
| essential for silicon provider in order to promote new devices and device |
| variants entering the market. Device aware debug views provide fast and |
| convenient access to all registers and fields as well as a detailed |
| description. This enables software developer to |
| develop and debug code most efficiently and adopt new devices early and |
| quickly.</p> |
| <p> |
| A standardized System View Description shall provide a common approach to |
| capturing peripheral debug related information in a machine readable files. |
| The scope of the contained information is agreed to match the level usually |
| provided by silicon vendors in their device reference manuals, however in a |
| formalized XML based format. There |
| are other description languages already available. IP-XACT from the SPIRIT |
| consortium is a prominent example. IP-XACT covers the register description |
| sufficiently, however it comprises many other aspects of the devices like |
| ports, bus-protocols, modeling, tool flows, etc. making a direct use of |
| IP-XACT too complex. The design of the SVD language is |
| taking some guidance from IP-XACT thus allowing straight forward conversion |
| from IP-XACT to CMSIS-SVD where IP-XACT device information is already |
| available.</p> |
| <p> |
| In a second step the CMSIS-SVD description shall be used for automatically |
| generating CMSIS compliant a device header file. This enables the |
| information in the header file to be consistent with what the debugger will |
| display and CMSIS compliant by construction. The header file generation will |
| require some additional pieces of information and therefore a future version |
| of the description will need to include some extensions for this purpose.</p> |
| <p> |
| Device aware debugging support is only one aspect of device |
| support essential to software development environments, however it is one of |
| the most time consuming and error prone ones.</p> |
| <h2><a name="2"></a>Motivation</h2> |
| <p> |
| |
| The software developer of microcontroller devices is faced with a growing number |
| of devices with an ever increasing number of peripheral blocks providing a wide |
| range of distinct and complex functionality. The development of drivers for |
| these peripherals is in the critical path of every project. Modern debuggers are supporting the software developer in getting the |
| software to run according to the requirements. A debugger providing peripheral awareness improves the |
| ability to access and interpret complex configuration and status information of |
| peripherals. Even though this is only one aspect of device support within microcontroller |
| development environments it is essential for the successful and timely adoption |
| of development tools and the device by the market.</p> |
| <p>Today software development environments address device aware |
| debugging in various ways. They either use documents or proprietary file formats |
| as input for providing peripheral views in the debuggers. |
| Extracting peripheral information from written documentation is a very time |
| consuming, tedious and error prone task. Having a file containing peripheral specific information to generate peripheral views |
| is going to make device support more affordable, reliable and timely. |
| The challenge for the tool providers is the support of many |
| different and incompatible file formats from a growing number of silicon vendors. |
| For silicon vendors it is time consuming and costly to engage with many tool |
| provider in order to achieve device support in a wide range of development |
| environments.</p> |
| <p>Standardizing on a System View Description aims to ease this challenge |
| by agreeing on a formal XML-based file format. In conjunction with supporting web server infrastructure silicon partner |
| shall upload and maintain such descriptions in a tool vendor agnostic device |
| database, hosted e.g. by the web server infrastructure |
| <a href="http://cmsis.arm.com"> |
| cmsis.arm.com</a> . Access control to sensitive information is managed on a per user |
| basis. This allows silicon vendors to upload information for devices that have |
| not been made public. </p> |
| <p>Such an approach provides benefits for silicon and tool vendors as well as |
| software developers of Cortex-M based microcontroller devices</p> |
| <ul> |
| <li>timely and accurate device support provided by a whole range of tool providers </li> |
| <li>tool providers become more efficient in supporting a multitude of devices |
| and device variants</li> |
| <li>less interaction required between silicon vendors and the |
| tool providers</li> |
| <li>silicon provider has control over and maintains the System View |
| Description during the life cycle of the device</li> |
| <li>high quality device support in terms of completeness and correctness of |
| device aware debugging</li> |
| <li>improved productivity and user experience for the software developer</li> |
| </ul> |
| <h2><a name="3"></a>Requirements</h2> |
| <p>The debug description shall capture the information about all |
| the peripherals contained in a specific device. This section describes which |
| items of information are deemed relevant for a debugger. Silicon vendors are expected to |
| provide the System View Description for their devices, matching the information |
| contained in device reference manuals. The System View Description shall be suitable for straight forward |
| generation from existing databases like IP-XACT descriptions or SIDSC. The size |
| of device description is a concern and therefore redundancy in the description |
| shall be avoided. The size of SVD files affects the efficiency of |
| distribution as well as the loading time by the development tools. Last but not least manual editing of SVD files shall be possible for |
| the purpose of customization by SW developers.</p> |
| <h4>Required content of the description</h4> |
| <p>From a programmer's perspective a peripheral can be seen as a set of registers |
| with unique<em> names</em> being mapped to fixed<em> addresses</em> allocated |
| within a defined <em>range</em> of an address space.</p> |
| <p>From a debugger's point of view read accesses to a physical register need to be |
| executed in order to display its current value. The debugger executes a write |
| access to a register when a user edits its value. For this purpose the debugger |
| needs to know about the following additional attributes: </p> |
| <ul> |
| <li><em>minimal addressable unit </em>= smallest series of bits |
| identified by a unique address (e.g. byte-addressable memory) </li> |
| <li><em>register size</em> = number of bits forming a register (ARM Cortex-M usually |
| 32 bits)</li> |
| <li><em>access permission</em> = read and write, read only, |
| write only</li> |
| <li><em>access side effects</em> = accesses by the debugger must |
| be avoided if it has side effects. Some side effects may be |
| reversed by the debugger to compensate for the side effect</li> |
| </ul> |
| <p>In many cases peripheral registers are partitioned into chunks of bits of |
| distinct functionality. In this document these chunks are referred to as <em> |
| field</em>. Each |
| register that consists of fields shall be described by a list |
| of <em>uniquely named</em> fields (Note: field names are not required to be |
| unique across registers). In order for a debugger to extract the |
| value of a field from the corresponding register the following attributes are required:</p> |
| <ul> |
| <li><em>most significant bit </em>= highest bit position of the |
| bit-field in the corresponding register</li> |
| <li><em>least significant bit</em> = lowest bit position of the |
| bit-field within the corresponding register</li> |
| <li><em>access permission</em> = read and write, read only, |
| write only</li> |
| </ul> |
| <p>An enumerated value maps a number to a specific descriptive string |
| representing the semantics of the value of a field. The debugger displays the |
| descriptive string rather than the number to simplify the access to the |
| information thus |
| avoiding the necessity of a look-up in the device reference manual. Each item of |
| an enumerated value has the following attributes:</p> |
| <ul> |
| <li><em>value</em> = value of the bit-field that corresponds to |
| the string attribute</li> |
| <li><em>name</em> = short string that describes the semantics of a |
| field when the corresponding value is set</li> |
| <li><em>description</em> = detailed description of the semantics |
| of the field when the corresponding value is set</li> |
| </ul> |
| <p>The hierarchical structure of the description looks like this:</p> |
| <p><strong>Device =</strong></p> |
| <ul> |
| <li> |
| <p> <strong>Peripherals</strong></p> |
| <ul> |
| <li> |
| <p class="style2"><strong>Peripheral</strong></p> |
| <ul> |
| <li> |
| <p class="style2"><strong>Registers</strong></p> |
| <ul> |
| <li> |
| <p class="style2"> |
| <strong>Register</strong></p> |
| <ul> |
| <li> |
| <p class="style2"> |
| <strong>Fields</strong></p> |
| <ul> |
| <li> |
| <p class="style2"><strong>Field</strong></p> |
| <ul> |
| <li> |
| <p class="style2"><strong>Enumerated Values</strong></p> |
| <ul> |
| <li> |
| <p class="style2"><strong>Enumerated Value</strong></p> |
| </li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| </ul> |
| |
| <p>One file can only contain a description for a single device or device family |
| sharing the identical description. Devices consists of a one or more peripherals. |
| Each peripheral contains |
| one or more registers, where each register may consist of one or more fields. |
| The values of a field maybe represented through descriptive strings and detailed |
| descriptions, the enumerated values.</p> |
| <p>In many cases there are multiple |
| instances of the same peripheral in a device (e.g. Timer0, Timer1, etc.). For |
| this reason the description has the concept of deriving a peripheral from a peripheral |
| that has already been described. The attribute <em>derivedFrom </em>specifies |
| such a relationship. |
| Similarly registers or fields can be reused within the device description. The |
| grouping of peripherals providing |
| similar functionality (e.g. Simple Timer, Complex Timer) is controlled via the element <em>groupName</em>. |
| All peripherals associated with the same group name are collectively listed under this group |
| in the order they have been specified in the file. |
| Collecting |
| similar or related peripherals into peripheral groups helps structuring the list |
| of peripherals e.g. in a drop down menu (tool dependent). Devices with a large |
| set of peripherals will benefit from this additional level of structure.</p> |
| <p>Each of the items (i.e. Device, Peripheral, Register and |
| Field) owns an <em>description </em>element containing verbose information about |
| the respective element. The description field plays |
| an important part in improving the software development productivity. Instead of |
| searching through the reference manual the detailed explanation from the manual |
| could become immediately accessible from within the development environment.</p> |
| <p>Details about the exact display format and layout of the peripheral view are |
| considered beyond the scope of the description. It is up to the tool vendor to |
| visualize the contained information appropriately. The |
| silicon vendor provides details about the device's peripherals that is commonly available. </p> |
| <p>System View Description files need to be validated for:</p> |
| <ol> |
| <li>syntactical correctness using XML-Schema checking utilities</li> |
| <li>consistency of the provided information (e.g. multiple registers mapped to the same address, |
| all registers located within the specified address ranges of a |
| peripheral, all fields are within the range of the register |
| size, etc.) by a utility developed by ARM (SVDConv.exe)</li> |
| <li> semantical correctness of the System View Description |
| against the silicon specification executed by the silicon vendor</li> |
| </ol> |
| <p>The SVD description format was extended by numerous elements during the |
| review period targeting version 1.0 and new extensions are expected for future |
| versions of this format. A new section named "vendorExtensions" has been added |
| to the end of the top level to allow silicon vendors and tool partners to |
| innovate and expand the description in order to overcome limitations of the |
| current specification until these can be incorporated into new versions of |
| CMSIS-SVD. <br> |
| </p> |
| |
| <h2> <a name="4"></a><span class="style9">Format</span></h2> |
| |
| <p> |
| The following section describes the SVD file format in detail. Each subsection |
| defines a single hierarchy level of the description and lists all mandatory |
| and optional language elements for that specific level including type |
| information for each element. Each element is discussed in more detail and a |
| brief snippet is provided as an example. The sequence of elements shown |
| below is binding. Optional elements are highlighted in green, blue elements |
| are mandatory unless they have been already specified globally on a higher |
| level.</p> |
| <p> |
| An XML-schema file is provided alongside this document for syntactical |
| checking of descriptions being developed.</p> |
| <h4><device schemaVersion="xs:decimal" <span class="style2"><em>xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xs:noNamespaceSchemaLocation="CMSIS-SVD_Schema_1_0.xsd</em></span>"></h4> |
| <p> <<span class="style2">name><em>xs:Name</em></name><br> |
| <version<em>>xs:string<</em>/version><br> |
| <description><em>xs:string</em></description><br> |
| </span> <<span class="style2">addressUnitBits><em>scaledNonNegativeInteger</em></addressUnitBits><br> |
| <width><em>scaledNonNegativeInteger</em> </width></span><br> |
| <br> |
| <span class="style4"> <</span><span class="style2"><span class="style4">size><em>scaledNonNegativeInteger</em></size><em><br> |
| </em> <access><em>accessType</em></access><br> |
| <resetValue><em>scaledNonNegativeIntege</em>r</resetValue><br> |
| <resetMask><em>scaledNonNegativeInteger</em></resetMask></span></span></p> |
| <p> <peripherals><br> |
| ...<br> |
| </peripherals><br> |
| <span class="style4"> <vendorExtensions><br> |
| ...<br> |
| </vendorExtensions></span></p> |
| <h4></device></h4> |
| <p>The <strong>device</strong> provides the outermost frame of the description. All other |
| elements like peripherals, registers and fields are described inside of this scope. A device contains one or more peripherals. |
| The optional elements size, access, resetValue and resetMask are used as default values throughout the |
| device description unless they get overruled on a lower level of the description |
| (e.g. peripheral or register).</p> |
| <h4>Mandatory items:</h4> |
| <p><strong>name = </strong>the unique name string is used to identify the device. |
| All devices of a silicon vendor are required to have a unique name. In case an |
| SVD description covers a family or series of devices, the name of the series or |
| family is placed here. The device names of the members of the series or family |
| are listed in <memberDevices></p> |
| <p><strong>description = </strong>string describing main features of a device |
| (e.g. CPU, clock frequency, peripheral overview, etc.)</p> |
| <p><strong>version = </strong>the string is defining the version of the |
| description for this device. Silicon vendors will maintain the description |
| throughout the lifecycle of the device and need to ensure that all updated and |
| released copies have a unique version string indicating the order in which. Note: this must not be used for |
| detailing the version of the device.</p> |
| <p> </p> |
| <p><strong>addressUnitBits = </strong>defines the number of data bits for each address |
| increment. The value for Cortex-M based devices is 8 (byte-addressable).</p> |
| <p><strong>width = </strong>defines the number of bits for the maximum single |
| transfer size allowed by the bus interface hence the maximum size of a single |
| register that can be defined for the address space. This information is relevant |
| for debuggers when determining the size of debug transfers. The expected value |
| for Cortex-M based devices is 32.</p> |
| <p><strong>peripherals = </strong>next level of description (see next section |
| for details)</p> |
| <h4>Optional Items:</h4> |
| <p><strong>size = </strong>defines the default bit-width of registers contained |
| in the device. This element can be overruled by re-specifying the size element on a lower level of the |
| description.</p> |
| <p><strong>access =</strong> defines the default access permissions for all |
| registers in the device. The allowed tokens are:<br> |
| - <em>read-only</em>: read access is permitted. Write operations have an undefined |
| result.<br> |
| - <em>write-only</em>: write access is permitted. Read operations have an |
| undefined result. <br> |
| -<em>read-write</em>: both read and write accesses are permitted. Writes affect |
| the state of the register and reads return a value related to the register<br> |
| -<em>writeOnce</em>: only the first write after reset has an effect on the |
| register. Read operations deliver undefined results<br> |
| -<em>read-writeOnce</em>: Read operations deliver a result related to the register |
| content. Only the first write access to this register after a reset will have an |
| effect on the register content.</p> |
| <p><strong>resetValue = </strong>defines the default value of all registers |
| after a reset. There are scenarios where SW developers need to know, what the |
| reset value of a register or field is. Even though listed as optional on this |
| level of the description, silicon vendors should ensure that this information is |
| provided for all registers. </p> |
| <p><strong>resetMask =</strong> defines those bit positions set to one to be |
| taken from resetValue element. All other elements are undefined. If a register |
| does not have a defined reset value the resetMask needs to be set to 0.</p> |
| <p><strong>vendorExtensions </strong>= the content and format of this section of |
| the description is unspecified. Silicon vendors may choose to provide additional |
| information. The assumption is that by default this section is completely |
| ignored by the debugger. It is up to the silicon vendor to specify the content |
| of this section and share the specification with the tool vendors. The new |
| elements shall be considered for a future version of the description format.</p> |
| <h4>Example:</h4> |
| <pre><device schemaVersion="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xs:noNamespaceSchemaLocation="CMSIS-SVD_Schema_1_0.xsd" > |
| <name>CMSIS_Cortex-M3</name> |
| <version>0.1</version> |
| <description>ARM Cortex-M3 based Microcontroller demonstration device</description> |
| <addressUnitBits>8</addressUnitBits> |
| <width>32</width> |
| <size>32</size> |
| <access>read-write</access> |
| <resetValue>0</resetValue> |
| <resetMask>0xffffffff</resetMask></pre> |
| <pre> <peripherals> |
| ... |
| </peripherals> |
| </device></pre> |
| <p>The device description above is at version 0.1 and uniquely identifies the |
| device by the name "CMSIS_Cortex-M3". The peripherals are memory mapped in a |
| byte-addressable address space with a bus width of 32 bits. The default size of |
| the registers contained in the peripherals is set to 32 bits. Unless redefined |
| for specific peripherals, registers or fields all registers are read-write |
| accessible. A reset value of 0 valid for all 32 bits as specified by the reset |
| mask is set for all registers unless overruled at a lower level of the description.</p> |
| <hr> |
| <h4><peripherals></h4> |
| <p> <peripheral><br> |
| ...<br> |
| </peripheral></p> |
| <p> ...</p> |
| <p> <peripheral><br> |
| ...<br> |
| </peripheral></p> |
| <h4></peripherals></h4> |
| <p>This construct sets the frame for all peripherals and peripheral groups contained in a device. This |
| creates a container element which ease-up processing with languages like Java.</p> |
| <hr> |
| <h4><peripheral <span class="style2"><span class="style4">derivedFrom=<em>"xs:Name"</em></span></span>></h4> |
| <p> <name><em>xs:Name</em></name><br> |
| <span class="style4"><version>xs:string</name></span><br> |
| <description><em>xs:string </em></description><br> |
| <span class="style4"><groupName><em>xs:string</em></groupName><br> |
| <prependToName><em>xs:string</em></prependToName><br> |
| <appendToName><em>xs:string</em></appendToName></span><br> |
| <span class="style4"><disableCondition><em>xs:string</em></disableCondition></span><br> |
| <baseAddress><em>scaledNonNegativeInteger</em></baseAddress><br> |
| <span class="style4"> <</span><span class="style2"><span class="style4">size><em>scaledNonNegativeInteger</em></size><em><br> |
| </em> <access><em>accessType</em></access><br> |
| <resetValue><em>scaledNonNegativeIntege</em>r</resetValue><br> |
| <resetMask><em>scaledNonNegativeInteger</em></resetMask></span></span></p> |
| <p> <span class="style10"><addressBlock><br> |
| <offset></span><em>scaledNonNegativeInteger</em><span class="style10"></offset><br> |
| <size></span><em>scaledNonNegativeInteger</em><span class="style10"></size><br> |
| <usage<em>>usageType<</em>/usage><br> |
| <em> </</em>addressBlock><em><br> |
| </em> ...<br> |
| </span> <span class="style10"><span class="style4"><addressBlock><br> |
| <offset></span></span><span class="style4"><em>scaledNonNegativeInteger</em></span><span class="style10"><span class="style4"></offset><br> |
| <size></span></span><span class="style4"><em>scaledNonNegativeInteger</em></span><span class="style10"><span class="style4"></size><br> |
| <usage><em>usageType</em></usage><br> |
| <em> </</em>addressBlock><br> |
| <interrupt><br> |
| <name><em>xs:string</em></name><br> |
| <value><em>scaledNonNegativeInteger</em></value><br> |
| </interrupt></span><em><br> |
| </em></span> <registers><br> |
| ...<br> |
| </registers></p> |
| <h4></peripheral></h4> |
| <p>A peripheral encloses the description of one or more registers belonging to |
| this named peripheral. The address range allocated in the address space for this |
| peripheral is defined through one or more address ranges. An address range is |
| specified relative to the base address of the peripheral. This information |
| allows to display a memory map overview for all peripherals. Please note that |
| such a memory map does not contain any information for memories and unoccupied |
| address ranges.</p> |
| <h4>Mandatory items:</h4> |
| <p><strong>name = </strong>name string used to identify the peripheral. Peripheral |
| names are required to be unique within the scope of a device.</p> |
| <p><strong>baseAddress </strong>= lowest address reserved or used by the peripheral</p> |
| <p><strong>description = </strong>string providing an overview of the purpose |
| and functionality of the peripheral</p> |
| <p><strong>addressBlock = </strong>a peripheral may occupy one or more disparate |
| blocks in the address space. An addressBlock is a complex element consisting of |
| the mandatory elements:<br> |
| <strong>offset</strong>: specifying the start address of an address block. It |
| is calculated from the sum of baseAddress and offset<br> |
| <strong>size</strong>: specifying the number of addressUnitBits being covered |
| by this address block. The end address of an address block is the sum of start |
| address and the size - 1.<br> |
| <strong>usage</strong>: the usage element is of <em>usageType </em>specifying |
| if the addresses within the specified address block is used for<strong> </strong> |
| <em>registers</em><strong> </strong>or <em>buffer</em><strong> </strong>or is <em>reserved</em>. |
| <br> |
| Note: registers must not be allocated |
| to an address within a reserved or buffer address range.</p> |
| <p><strong>registers = </strong>next lower level of description (see next section |
| for details)</p> |
| <h4>Optional items:</h4> |
| <p><strong>derivedFrom = </strong>this attribute specifies the name of a peripheral |
| that has already been described for this device. The description of that device |
| will be copied. It is mandatory to overwrite the name as well as the |
| addressOffset. All other specified information will overwrite the respective |
| elements in the copy.</p> |
| <p><strong>version = </strong>the string specifies the version of this |
| peripheral description.</p> |
| <p><strong>disableCondition = </strong>C language compliant logical expression |
| resulting in a true or false result. If "true" the refresh of the display |
| for this peripheral is disabled |
| and related accesses by the debugger are suppressed. Only constants and references to other registers |
| contained in the description are allowed: |
| <peripheral>-><register>-><field> (e.g.: (System->ClockControl->apbEnable == 0)). |
| Only the following operators are allowed [&&,||, ==, !=, >>, <<, &, |]. Warning! |
| This feature must only be use in case accesses from the debugger to registers of |
| un-clocked peripherals result in severe debugging failures. SVD is intended to |
| be fully static information and not include any run-time computation or |
| functions such capabilities may be added by the tools but is considered beyond |
| the scope of this description language.</p> |
| <p><strong>prependToName = </strong>all register names of this peripheral have |
| their names prepended with the string specified</p> |
| <p><strong>appendToName = </strong>all register names of this peripheral have |
| their names appended with the string specified</p> |
| <p><strong>size = </strong>defines the default bit-width of registers contained |
| in the device. This element can be overruled by re-specifying the size element on a lower level of the |
| description.</p> |
| <p><strong>access =</strong> defines the default access permissions for all |
| registers in the peripheral. The value can be reset on a lower level of the |
| description. The allowed tokens are:<br> |
| - <em>read-only</em>: read access is permitted. Write operations have an undefined |
| result.<br> |
| - <em>write-only</em>: write access is permitted. Read operations have an |
| undefined result. <br> |
| -<em>read-write</em>: both read and write accesses are permitted. Writes affect |
| the state of the register and reads return a value related to the register<br> |
| -<em>writeOnce</em>: only the first write after reset has an effect on the |
| register. Read operations deliver undefined results<br> |
| -<em>read-writeOnce</em>: Read operations deliver a result related to the register |
| content. Only the first write access to this register after a reset will have an |
| effect on the register content.</p> |
| <p><strong>resetValue = </strong>defines the default value of all registers |
| after a reset but can be set for individual registers and fields on a lower |
| level of the description.</p> |
| <p><strong>resetMask =</strong> defines those bit positions set to one to be |
| taken from resetValue element. All other elements are undefined. This is the |
| default value for the whole peripheral but can be readjusted on lower levels. If |
| a register does not have a defined reset value the resetMask needs to be set to |
| 0.</p> |
| <p><strong>interrupt = </strong>is a complex type that consists of the <strong>name</strong> of |
| the interrupt and the associated enumeration<strong> value</strong>. A peripheral can also have |
| multiple associated interrupts. This entry is mainly intended for information |
| only purposes in order to display the interrupts and respective interrupt |
| numbers associated with a peripheral.</p> |
| <h4>Example:</h4> |
| <pre>... |
| <peripheral> |
| <name>Timer0</name> |
| <version>1.0.32</version> |
| <description>Timer 0 is a simple 16 bit timer counting down ... </description> |
| <baseAddress>0x40000000</baseAddress> |
| <addressBlock> |
| <offset>0x0</offset> |
| <size>0x400</size> |
| <usage>registers</usage> |
| </addressBlock> |
| <interrupt><name>TIM0_INT</name><value>34</value></interrupt> |
| <registers> |
| ... |
| </registers> |
| </peripheral> |
| <peripheral derivedFrom="Timer0"> |
| <name>Timer1</name> |
| <baseAddress>0x40000400</baseAddress> |
| </peripheral> |
| |
| ...</pre> |
| <hr> |
| <h4><registers> ... </registers></h4> |
| <p>This construct sets the frame for all registers contained in a peripheral. |
| This creates container elements which ease-up processing with languages like Java.</p> |
| <hr> |
| <h4><register <span class="style2">derivedFrom=<em>xs:Name</em></span>></h4> |
| <p> <span class="style4"><dim><em>scaledNonNegativeInteger</em></dim><br> |
| <dimIncrement><em>scaledNonNegativeInteger</em></dimIncrement><br> |
| <dimIndex><em>xs:string</em></dimIndex></span><br> |
| <<span class="style2">name><em>xs:Name</em></name><br> |
| <span class="style4"><displayName><em>xs:string</em></displayName></span><br> |
| </span> <span class="style2"><description><em>xs:string</em></description></span><br> |
| <span class="style2"> <span class="style4"><alternateGroup><em>xs:Name</em></alternateGroup></span><br> |
| </span> <span class="style2"> <addressOffset><em>scaledNonNegativeInteger</em> |
| </addressOffset><br> |
| <span class="style5"> <size><em>scaledNonNegativeInteger</em></size><br> |
| </span><span class="style4"> </span><span class="style5"> <access><em>accessType</em></access><br> |
| </span><span class="style4"><</span><span class="style5">resetValue><em>scaledNonNegativeInteger</em></resetValue><br> |
| <resetMask><em>scaledNonNegativeInteger</em></resetMask><br> |
| </span> |
| </span><span class="style4"> <modifiedWriteValues><em>writeValueType</em></modifiedWriteValues><br> |
| <writeConstraint><em>writeConstraintType</em></writeConstraint><br> |
| <readAction><em>readActionType</em> </readAction></span><span class="style2"><br> |
| </span> <span class="style4"><fields><br> |
| ...<br> |
| </fields></span> </p> |
| <h4></register></h4> |
| <p>The definition of registers is the central part of the description. A |
| register may use its complete size for a single purpose and therefore not |
| consist of fields. Otherwise the description |
| of fields is mandatory.</p> |
| <h4>Mandatory items:<br> |
| </h4> |
| <p><strong>name = </strong>name string used to identify the register. Register |
| names are required to be unique within the scope of a peripheral.</p> |
| <p><strong>description = </strong>string describing the details of the register.</p> |
| <p><strong>addressOffset = </strong>value defining the address of the register relative to |
| the baseAddress defined by the peripheral the register belongs to.<br> |
| </p> |
| <p><span class="style5">The following elements can be omitted</span> if the corresponding value has been set |
| on a higher level of the description and matches the value required for this register:</p> |
| <p><strong>size =</strong>value defining the bit-width of the register</p> |
| <p><strong>access =</strong> predefined tokens: read-only, write-only, read-write, |
| writeOnce, read-writeOnce strings defining the allowed |
| accesses for this register.</p> |
| <p><strong>resetValue =</strong> element defining the value of the register |
| immediately after a reset.</p> |
| <p><strong>resetMask= </strong>element specifying those bits of the resetValue that |
| are defined<strong> </strong>(bit positions containing a 0 bit are ignored, bit |
| positions containing a 1 bit are taken from the corresponding bit position of |
| the resetValue). If a register does not have a defined reset value the resetMask |
| needs to be set to 0.</p> |
| <h4>Optional items:</h4> |
| <p><strong>dim = </strong>if this field is specified the value defines the |
| number of elements in an array of registers.</p> |
| <p><strong>dimIncrement =</strong> if dim is specified this element becomes |
| mandatory and specifies the address increment in between |
| two neighboring registers of the register array in the address map.</p> |
| <p><strong>dimIndex = </strong>this element specifies the substrings within the |
| register array names that will replace the %s within the register name. By |
| default the index is a decimal value starting with 0 for the first register. |
| Examples:<br> |
| <dim>6</dim> <dimIncrement>4</dimIncrement> <dimIndex>A,B,C,D,E,Z</dimIndex> |
| <name>GPIO_%s_CTRL</name> ...<br> |
| => GPIO_A_CTRL, GPIO_B_CTRL, GPIO_C_CTRL, GPIO_D_CTRL, GPIO_E_CTRL, |
| GPIO_Z_CTRL<br> |
| <dim>4</dim> <dimIncrement>4</dimIncrement> <dimIndex>3-6</dimIndex> |
| <name>IRQ%s</name> ... <br> |
| => IRQ3, IRQ4, IRQ5, IRQ6 </p> |
| <p><strong>displayName = </strong>when used, this is the string being used by a |
| graphical frontend to visualize the register otherwise the name element is used. |
| Note: the display name may contain special characters and white spaces. It also |
| uses "%s" as the place holder for the dimIndex substring.</p> |
| <p><strong>alternateGroup =</strong> when used, this element specifies a name of |
| a group that all alternate register with the same name a associated with. At the |
| same time it indicates that there is a register description allocating the same |
| absolute address in the address space. </p> |
| <p><strong>modifiedWriteValues = </strong>element to describe the manipulation of |
| data written to a register. If not specified the value written to the field is the |
| value stored in the field. The other options are bitwise operations: <br> |
| <em>oneToClear:</em> write data bits of one shall clear (set to zero) the |
| corresponding bit in the register<br> |
| <em>oneToSet:</em> write data bits of one shall set (set to one) the |
| corresponding bit in the register<br> |
| <em>oneToToggle:</em> write data bits of one shall toggle (invert) the |
| corresponding bit in the register<br> |
| <em>zeroToClear:</em> write data bits of zero shall clear (set to zero) |
| the corresponding bit in the register<br> |
| <em>zeroToSet:</em> write data bits of zero shall set (set to one) the |
| corresponding bit in the register<br> |
| <em>zeroToToggle:</em> write data bits of zero shall toggle (invert) the |
| corresponding bit in the register<br> |
| <em>clear:</em> after a write operation all bits in the field are cleared (set to |
| zero)<br> |
| <em>set:</em> after a write operation all bits in the field are set (set to one)<br> |
| <em>modify:</em> after a write operation all bit in the field may be modified |
| (default)</p> |
| <p><strong>writeConstraint: </strong>has a set of options:<br> |
| <em>writeAsRead</em> = if true only the last read value can be written<br> |
| <em>useEnumeratedValues</em> = if true only those values listed in the |
| enumeratedValues list are considered valid write values<br> |
| <em>minimum</em> = specifies the smallest number to be written to the |
| register<br> |
| <em>maximum</em> = specifies the largest number to be written to the |
| register</p> |
| <p><strong>readAction: </strong>if set it specifies the side effect following |
| read operations. If not set the register is not modified following a read |
| operations. The defined side effects are:<br> |
| <em>clear:</em> indicates that the register is cleared (set to zero) |
| following a read operation<br> |
| <em>set:</em> indicates that the register is set (set to ones) following a |
| read operation<br> |
| <em>modify</em>: indicates that the register is modified in some way |
| after a read operation<br> |
| <em>modifyExternal: </em>indicates that one or more dependent resources |
| other than the current register |
| are immediately affected by a read (it is recommended that the register |
| description specifies these dependencies). Debuggers are not expected to read |
| this register location unless explicitly instructed by user.</p> |
| <p><strong>fields = </strong>next lower level of description (see next section |
| for details).</p> |
| <h4>Optional attribute:</h4> |
| <p><strong>derivedFrom = </strong>specifies the name of the register to be |
| replicated. Elements being specified underneath will override the values specified |
| from the register being derived from. Note that it is mandatory to overwrite at |
| least name and addressOffset.</p> |
| <h4>Example:</h4> |
| <pre>... |
| <register> |
| <name>TimerCtrl0</name> |
| <description>Timer Control Register</description> |
| <addressOffset>0x0</addressOffset> |
| <access>read-write</access> |
| <resetValue>0x00008001</resetValue> |
| <resetMask>0x0000ffff</resetMask> |
| <size>32<size> |
| <fields> |
| ... |
| </fields> |
| </register> |
| <register derivedFrom="TimerCtrl0"> |
| <name>TimerCtrl1</name> |
| <addressOffset>0x4<addressOffset> |
| </register> |
| ...</pre> |
| <hr> |
| <h4><fields> ... </fields></h4> |
| <p>This construct sets the frame for all fields contained in a register. |
| This creates container elements which ease-up processing with languages like Java.</p> |
| <hr> |
| <h4> <field <span class="style2">derivedFrom=<em>"xs:Name</em>"</span>></h4> |
| <p> <span class="style2"> <name><em>xs:Name</name><br> |
| </em></span> <description><em>xs:string</em></description><br> |
| <span class="style5"> </span><span class="style2"><span class="style5"><em> </em> |
| </span><<span class="style5">bitOffset><em>scaledNonNegativeInteger</</em>bitOffset> |
| </span><<span class="style5">bitWidth><em>scaledNonNegativeInteger</em></bitWidth><br> |
| </span><span class="style6">or</span><span class="style5"><br> |
| <lsb>scaledNonNegativeInteger</lsb> <msb>scaledNonNegativeInteger</msb><br> |
| </span><span class="style6">or</span><span class="style5"><br> |
| <bitRange><em>pattern</em></bitRange><br> |
| <access><em>accessType</em></access><br> |
| </span></span><span class="style4"> <modifiedWriteValues><em>writeValueType</em></modifiedWriteValues><br> |
| <writeConstraint><em>writeConstraintType</em></writeConstraint><br> |
| <readAction><em>readActionType</em> </readAction></span><span class="style2"><br> |
| </span> <span class="style4"><enumeratedValues><br> |
| ...<br> |
| </enumeratedValues></span></p> |
| <h4></field></h4> |
| <p>A bit-field has a name that is unique for the register it belongs to. The |
| position and size within the register is either described by the combination of |
| the least significant bit's position (lsb) and the most significant bit's |
| position (msb) or the lsb and the size, specifying the bit-width of the |
| field. A field may define an enumeratedValue in order to make the display |
| more intuitive to read. </p> |
| <h4>Mandatory items:</h4> |
| <p><strong>name = </strong>name string used to identify the field. Field names |
| are required to be unique within the scope of a register.<br> |
| </p> |
| <p><strong>description = </strong>string describing the details of the register.<br> |
| </p> |
| <p>There are 3 ways to describe a field to be used mutually exclusive:<br> |
| a) specifying bitOffset and bitWidth (IP-XACT like)<br> |
| b) specifying lsb and msb of the field.<br> |
| c) specifying a bit range in the format "[<msb>:<lsb>]"</p> |
| <p><strong>bitOffset = </strong>value defining the position of the least significant bit |
| of the field within the register it belongs to.<br> |
| <strong>bitWidth = </strong>value defining the bit-width of the bitfield within the |
| register it belongs to.<br> |
| </p> |
| <p> |
| <strong>lsb =</strong> value defining the bit position of the least significant |
| bit within the register it belongs to.<br> |
| <strong>msb =</strong> value defining the bit position of the most significant |
| bit within the register it belongs to. |
| </p> |
| <p><strong>bitRange = </strong>a string in the format: [<msb>:<lsb>]<br> |
| </p> |
| <h4>Optional items:</h4> |
| <p><strong>derivedFrom = </strong>the field is cloned |
| from a previously defined field with a unique name.</p> |
| <p><strong>access =</strong> predefined strings defining the allowed |
| accesses for this register: <em>read-only, write-only, read-write, writeOnce, |
| read-writeOnce</em><strong>.</strong> Can be omitted if it matches the access permission set for the parent register.</p> |
| <p><strong>enumeratedValues = </strong>next lower level of description (see next section |
| for details)</p> |
| <p><strong>modifiedWriteValues = </strong>element to describe the manipulation of |
| data written to a field. If not specified the value written to the field is the |
| value stored in the field. The other options are bitwise operations: <br> |
| <em>oneToClear:</em> write data bit of one shall clear (set to zero) the |
| corresponding bit in the field<br> |
| <em>oneToSet:</em> write data bit of one shall set (set to one) the corresponding |
| bit in the field<br> |
| <em>oneToToggle:</em> write data bit of one shall toggle (invert) the |
| corresponding bit in the field<br> |
| <em>zeroToClear:</em> write data bit of zero shall clear (set to zero) the |
| corresponding bit in the field<br> |
| <em>zeroToSet:</em> write data bit of zero shall set (set to one) the |
| corresponding bit in the field<br> |
| <em>zeroToToggle:</em> write data bit of zero shall toggle (invert) the |
| corresponding bit in the field<br> |
| <em>clear:</em> after a write operation all bits in the field are cleared (set to |
| zero)<br> |
| <em>set:</em> after a write operation all bits in the field are set (set to one)<br> |
| <em>modify:</em> after a write operation all bit in the field may be modified |
| (default)</p> |
| <p><strong>writeConstraint: </strong>has a set of options:<br> |
| <em>writeAsRead</em> = if true only the last read value can be written<br> |
| <em>useEnumeratedValues</em> = if true only those values listed in the |
| enumeratedValues list are considered valid write values<br> |
| <em>minimum</em> = specifies the smallest number to be written to the field<br> |
| <em>maximum</em> = specifies the largest number to be written to the field</p> |
| <p><strong>readAction: </strong>if set it specifies the side effect following |
| read operations. If not set the field is not modified following a read |
| operations. The defined side effects are:<br> |
| <em>clear:</em> indicates that the field is cleared (set to zero) |
| following a read operation<br> |
| <em>set:</em> indicates that the field is set (set to ones) following a |
| read operation<br> |
| <em>modify</em>: indicates that the field is modified in some way after a |
| read operation |
| <br> |
| <em>modifyExternal: </em>indicates that one or more dependent resources |
| other than this field are immediately affected by a read (it is recommended that |
| the field description specifies these dependencies). Debuggers are not expected |
| to read the field unless explicitly instructed by user.</p> |
| <h4>Example:</h4> |
| <pre>... |
| <field> |
| <name>TimerCtrl0_IntSel</name> |
| <description>Select interrupt line t<span class="style8">hat is triggered by timer overflow</span>.</description> |
| <bitOffset>1</bitOffset> |
| <bitWidth>3</bitWidth> |
| <access>read-write</access> |
| <resetValue>0x0</resetValue> |
| <modifiedWriteValues>oneToSet</modifiedWriteValues> |
| <writeConstraint> |
| <range> |
| <minimum>0</minimum> |
| <maximum>5</maximum> |
| </range> |
| </writeConstraint> |
| <readAction>clear</readAction> |
| |
| <enumeratedValues> |
| ... |
| </enumeratedValues> |
| </field> |
| ...</pre> |
| <hr> |
| <h4 class="style3"><enumeratedValues <span class="style2"> |
| <span class="style4">derivedFrom=</span><em>"<span class="style4">xs:Name"</span></em></span>></h4> |
| <p> <span class="style2"><span class="style4"> <name><em>xs:Name</em></name</span></span>><span class="style4"><br> |
| <usage><em>usageType</em></usage></span><br> |
| <enumeratedValue><br> |
| ...<br> |
| </enumeratedValue></p> |
| <p> ... </p> |
| <p> <enumeratedValue><br> |
| ...<br> |
| </enumeratedValue></p> |
| <h4></enumeratedValues></h4> |
| <p>An enumerated value provides one or more enumeration items (enumeratedValue), defining a map |
| between all possible values of the bit-field it belongs to and the corresponding |
| human readable semantics of that value.</p> |
| <p>Mandatory items:<br> |
| <strong>enumeratedValue = </strong>next lower level of description (see next section |
| for details)</p> |
| <p>Optional items:<br> |
| <strong>derivedFrom = </strong>the enumeratedValues can be copied or derived |
| from a previously defined enumeratedValue that has been given a unique name.<br> |
| <strong>name =</strong> name string to identify an enumeratedValue. Named |
| enumeratedValues need to be unique in the scope of a device in order to be reusable |
| throughout the description of a device.<br> |
| <strong>usage = </strong>possible values are <strong>read, write </strong>or |
| <strong>read-write.</strong> This allows to specify two different enumerated values |
| depending whether it is to be used for a read or a write access. If not specified the enueratedValues are valid for read and write.</p> |
| <h4>Example:</h4> |
| <pre>... |
| <enumeratedValues> |
| <name>TimerIntSelect</name> |
| <usage>read-write</usage> |
| <enumeratedValue> |
| <name>disabled</name> |
| <description>disabled bit</description> |
| <value>0</value> |
| </enumeratedValue> |
| ... |
| <enumeratedValue> |
| <name>reserved</name> |
| <description>reserved values. Do not use</description> |
| <isDefault>true</isDefault> |
| </enumeratedValue> |
| </enumeratedValues> |
| ...</pre> |
| <hr> |
| <h4><enumeratedValue></h4> |
| <p> <name<em>>xs:name</em></name><br> |
| <span class="style10"><span class="style4"><description>xs:<em>string</em></description></span><br> |
| </span><em> <</em>value<span class="style2">><em>scaledNonNegativeInteger</em></value><em><br> |
| |
| </em>or<em><br> |
| <</em>isDefault><em>xs:boolean</em></isDefault><em><br> |
| </em></span></p> |
| <h4></enumeratedValue></h4> |
| <p>An enumeratedValue defines a map between a value and the string reading the |
| corresponding human readable semantics for that value in a brief and a detailed |
| version</p> |
| <h4>Mandatory items:</h4> |
| <p><strong>name=</strong> brief string verbally describing the semantics of the value |
| defined for this enumeratedValue. E.g. used for display in visualization of a bit-field |
| instead of the value.</p> |
| <p> |
| <strong>value = </strong>defines the constant of the bit-field that the name |
| corresponds to<strong>.</strong></p> |
| <p><strong>isDefault = </strong>defines the name and description for all other |
| values that are not explicitly listed</p> |
| <h4>Optional item:</h4> |
| <p><strong>description = </strong>extended string verbally describing the semantics |
| of the value defined for this enumeratedValue in full detail.</p> |
| <h4>Example:</h4> |
| <pre>... |
| <enumeratedValue> |
| <name>disabled</name> |
| <description>Timer does not generate interrupts</description> |
| <value>0</value> |
| </enumeratedValue> |
| ... |
| <enumeratedValue> |
| <name>enabled</name> |
| <description>Timer does not generate interrupts</description> |
| <isDefault>true</isDefault> |
| </enumeratedValue> |
| |
| ...</pre> |
| <hr> |
| <h4>Names</h4> |
| <p>Names shall comply with ANSI C variable naming restrictions.</p> |
| <h4>Constants</h4> |
| <p>Number constants shall be entered in hexadecimal, decimal or binary format.</p> |
| <ul> |
| <li>hexadecimal is indicated by a leading "0x"</li> |
| <li>binary format is indicated by a leading "#"</li> |
| <li>all other formats are interpreted as decimal numbers</li> |
| <li>the value tag in enumeratedValue accepts do not care bits |
| represented by "x"</li> |
| </ul> |
| <h4><b>Comments</b> </h4> |
| <p>Comments have the standard XML format <strong>"<!--"</strong> starts a comment |
| <strong><span class="style2">"-->"</span></strong> terminates a comment</p> |
| <h2>Example</h2> |
| <pre> |
| <?xml version="1.0" encoding="utf-8"?> |
| |
| <device schemaVersion="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xs:noNamespaceSchemaLocation="CMSIS-SVD_Schema_1_0.xsd" > |
| <name>Cortex_M3_Sample</name> |
| <version>0.1</version> |
| <description>ARM Cortex-M3 based Microcontroller dummy device</description> |
| <!-- Bus Interface Properties --> |
| <!-- Cortex-M3 is byte addressable --> |
| <addressUnitBits>8</addressUnitBits> |
| <!-- the maximum data bit width accessible within a single transfer is 32bits --> |
| <width>32</width> |
| |
| <!-- Register Default Properties --> |
| <!-- the size of the registers is set to a bit width of 32. This can be overruled for individual peripherals and/or registers --> |
| <size>32</size> |
| <!-- the access to all registers is set to be readable and writeable. This can be overruled for individual peripherals and/or registers --> |
| <access>read-write</access> |
| <!-- for demonstration purposes the resetValue for all registers of the device is set to be 0. This can be overruled within the description --> |
| <resetValue>0</resetValue> |
| <!-- the resetMask = 0 specifies that by default no register of this device has a defined reset value --> |
| <resetMask>0</resetMask> |
| |
| <peripherals> |
| <peripheral> |
| <name>Timer0</name> |
| <description>A simple 16 bit timer counting down ... </description> |
| <groupName>Timer</groupName> |
| <baseAddress>0x40000000</baseAddress> |
| <!-- the first addressBlock is occupied by registers. The second block is reserved -> no access permission --> |
| <addressBlock> |
| <offset>0</offset> |
| <size>0x8</size> |
| <usage>registers</usage> |
| </addressBlock> |
| <addressBlock> |
| <offset>0x8</offset> |
| <size>0x3f8</size> |
| <usage>reserved</usage> |
| </addressBlock> |
| <interrupt> |
| <name>TIM0_IRQn</name> |
| <value>34</value> |
| </interrupt> |
| <registers> |
| <register> |
| <name>TimerCtrl0</name> |
| <!-- the display name is an unrestricted string. --> |
| <displayName>Timer Ctrl 0</displayName> |
| <description>Timer Control Register</description> |
| <addressOffset>0x0</addressOffset> |
| <!-- size=32, access=read-write, resetValue=0x0, resetMask=0xffffffff, volatile=false --> |
| <fields> |
| <field> |
| <name>TimerCtrl0_En</name> |
| <description>Enable Bit activates the timer.</description> |
| <!-- Spirit like bit range description: [0:0] --> |
| <bitOffset>0</bitOffset> |
| <bitWidth>1</bitWidth> |
| <!-- Writing 1 enables, writing 0 has no effect --> |
| <modifiedWriteValues>oneToSet</modifiedWriteValues> |
| <!-- The write constraint is defined to be that only the values provided by the enumeratedValues below are allowed --> |
| <writeConstraint> |
| <useEnumeratedValues>true</useEnumeratedValues> |
| </writeConstraint> |
| <!-- there is no side effect on reads, therefore <readAction> is not set --> |
| <!-- oneBitEnable named enumeration that can be reused in other parts of the description --> |
| <enumeratedValues> |
| <name>oneBitEnable</name> |
| <!-- the same enumerated Values are used for read and write. This default is assumed when this tag is missing --> |
| <usage>read-write</usage> |
| <enumeratedValue> |
| <name>enabled</name> |
| <description>Timer is enabled and active</description> |
| <value>0x0</value> |
| </enumeratedValue> |
| <enumeratedValue> |
| <name>disabled</name> |
| <description>Timer is disabled and inactive</description> |
| <value>0x1</value> |
| </enumeratedValue> |
| </enumeratedValues> |
| </field> |
| <field> |
| <name>TimerCtrl0_Dis</name> |
| <description>Disable Bit deactivates the timer.</description> |
| <!-- Spirit like bit range description: [1:1] --> |
| <bitOffset>1</bitOffset> |
| <bitWidth>1</bitWidth> |
| <!-- Writing 1 sets, writing 0 has no effect --> |
| <modifiedWriteValues>oneToSet</modifiedWriteValues> |
| <!-- The write constraint is defined to be that only the values provided by the enumeratedValues below are allowed --> |
| <writeConstraint> |
| <useEnumeratedValues>true</useEnumeratedValues> |
| </writeConstraint> |
| <!-- there is no side effect on reads, therefore <readAction> is not set --> |
| <!-- oneBitEnable named enumeration that can be reused in other parts of the description --> |
| <enumeratedValues derivedFrom="oneBitEnable"></enumeratedValues> |
| </field> |
| <field> |
| <name>TimerCtrl0_Int</name> |
| <description>Select interrupt line that is triggered by timer overflow.</description> |
| <!-- the position of the bit field is described in the bitRange style. --> |
| <bitRange>[4:2]</bitRange> |
| <enumeratedValues> |
| <enumeratedValue> |
| <name>disabled</name> |
| <description>Timer does not generate interrupts</description> |
| <value>0</value> |
| </enumeratedValue> |
| <enumeratedValue> |
| <name>int 0</name> |
| <description>Timer does generate interrupts on interrupt line 0</description> |
| <value>1</value> |
| </enumeratedValue> |
| <enumeratedValue> |
| <name>int 1</name> |
| <description>Timer does generate interrupts on interrupt line 1</description> |
| <value>2</value> |
| </enumeratedValue> |
| <enumeratedValue> |
| <name>int 2</name> |
| <description>Timer does generate interrupts on interrupt line 2</description> |
| <value>3</value> |
| </enumeratedValue> |
| <enumeratedValue> |
| <name>int 3</name> |
| <description>Timer does generate interrupts on interrupt line 3</description> |
| <value>4</value> |
| </enumeratedValue> |
| <enumeratedValue> |
| <name>int 4</name> |
| <description>Timer does generate interrupts on interrupt line 4</description> |
| <value>5</value> |
| </enumeratedValue> |
| <!-- this is the default element. All the valid value not listed above (6,7) have the following name and description --> |
| <enumeratedValue> |
| <name>reserved</name> |
| <description>Timer is configured incorrectly and the functionality is considered unpredictable</description> |
| <isDefault>true</isDefault> |
| </enumeratedValue> |
| </enumeratedValues> |
| </field> |
| </fields> |
| </register> |
| <register> |
| <name>TimerCounter0</name> |
| <description>Timer0 16 Bit Counter Register</description> |
| <addressOffset>0x4</addressOffset> |
| <size>16</size> |
| </register> |
| <!-- a copy of the counter register TimerCounter0 with the name="TimerCounter1" and the addressOffset="0x8" --> |
| <register derivedFrom="TimerCounter0"> |
| <name>TimerCounter1</name> |
| <addressOffset>0x6</addressOffset> |
| </register> |
| <!-- ... this is a restricted demo example and a real timer peripheral would have more register to be complete --> |
| </registers> |
| </peripheral> |
| <!-- a copy of Timer0 with the name="Timer1 and the baseAddress="0x40000400" --> |
| <peripheral derivedFrom="Timer0"> |
| <name>Timer1</name> |
| <baseAddress>0x40000400</baseAddress> |
| <interrupt> |
| <name>TIM1_IRQn</name> |
| <value>35</value> |
| </interrupt> |
| </peripheral> |
| </peripherals> |
| </device></pre> |
| |
| <h2><a name="6"></a>Questions & Answers</h2> |
| <h3>Is there any relation between the System View Description and the CMSIS |
| standard?</h3> |
| <p>Initiallly there was no immediate link but both initiatives had a common goal: |
| Create a sound software development eco-system for Cortex-M based |
| Microcontroller, giving the customers the free choice of devices and software |
| development environments and all resources required for a successful product |
| development in a single location. Meanwhile we have started to generate |
| CMSIS compliant device header files from the same CMSIS-SVD description. We will |
| introduce a small number of additional description tags in the next version of |
| the specification. The benefit is the synchronization between symbols used in |
| the application and the symbols displayed by the debugger. </p> |
| <h3>Why does the format not provide constructs like macros and |
| conditional statements?</h3> |
| <p>It is assumed that the description is generated from other sources and |
| therefore such concepts would only complicate the language unnecessarily. It is |
| recommended to use a standard C pre-processor to generate the debug description |
| format from a redundancy optimized description.</p> |
| <h3>Do we need to consider endianess in the description?</h3> |
| <p>This should be specified on a device configuration level and is not specific |
| to the visualization of peripheral details in a System View. Endianess becomes |
| relevant when using bit fields in the CMSIS compliant device header file.</p> |
| <h3>Is the System View Description limited to Cortex-M based devices ?</h3> |
| |
| |
| <p>There may have been assumptions made about the structure of the device due to |
| it being developed around a Cortex-M processor. E.g. that all peripherals are |
| assumed to be memory mapped and to reside in a single address space. It is quite |
| likely that the description format may also serve other architectures |
| sufficiently. There is no intent to limit the format to Cortex-M |
| processor based devices. </p> |
| |
| |
| </body></html> |