Patched SVD files do not meet the requirements through svdconv tool

[KamilDuljas]

Example:
svdconv.exe stm32f7x6.svd
return

Found 0 Error(s) and 1 Warning(s).

svdconv.exe stm32f7x6.svd.patched
return
Found 1060 Error(s) and 292 Warning(s).

The patches schould be compatible with CMSIS tools and Vendors architecture manners.

[KamilDuljas]

In relation to the comment:
Open-CMSIS-Pack/devtools#814 (comment)

forward reference is not supported and this restriction will be added to CMSIS documentation

[burrbull]

I've made fast fix. Could you try stm32f7x6.svd.patched.new.zip ?

[KamilDuljas]

Still the same. The solution is guaranting the ordering derivedFrom entry against to reference to type as I shown in
Open-CMSIS-Pack/devtools#814
For example: First declare USART1 and then use derivedFrom="USART1". The svdFile still use forward reference

[burrbull]

where can I load svdconv for linux?

highly prefered by direct link for ci

[KamilDuljas]

Compile source only
https://github.com/Open-CMSIS-Pack/devtools

[burrbull]

it is awful

[KamilDuljas]

It's binary for Windows:
https://drive.google.com/drive/folders/1g4zcyAUWLmCwDw-jHGXfO2i8zeHHyhHo?usp=share_link

[burrbull]

I've added field name to derivedFrom which was the real issue. Then I reordered fields to place derived first, but svdconv still not happy:

*** ERROR M206: Z:/home/burrbull/tests/stm32f7x6.patched.supernew.svd (Line 9422) 
  DerivedFrom not found: 'PUPDR0.PUPDR0'

*** INFO M211: Z:/home/burrbull/tests/stm32f7x6.patched.supernew.svd (Line 9422) 
  Ignoring DerivedFrom  (see previous message)

*** INFO M211: Z:/home/burrbull/tests/stm32f7x6.patched.supernew.svd (Line 9422) 
  Ignoring EnumeratedValues  (see previous message)

*** ERROR M206: Z:/home/burrbull/tests/stm32f7x6.patched.supernew.svd (Line 9429) 
  DerivedFrom not found: 'PUPDR0.PUPDR0'

stm32f7x6.patched.supernew.svd.zip

[KamilDuljas]

Hmm, You need read deeper CMSIS schema :p

            <field derivedFrom="PUPDR0">
              <name>PUPDR1</name>
              <description>Port x configuration bits (y =               0..15)</description>
              <bitOffset>2</bitOffset>
              <bitWidth>2</bitWidth>
            </field>

Above example works fine. Look also on USART. It uses "derviedFrom" as attribute of pheripherial node:

 <peripheral derivedFrom="USART1">
      <name>USART6</name>
      <baseAddress>0x40011400</baseAddress>
      <interrupt>
        <name>USART6</name>
        <description>USART6 global interrupt</description>
        <value>71</value>
      </interrupt>
    </peripheral>

[KamilDuljas]

<xs:complexType name="fieldType">
    <xs:sequence>
      <xs:group    ref="dimElementGroup" minOccurs="0"/>
      <!-- name specifies a field's name. The System Viewer and the device header file will
           use the name of the field as identifier -->
      <xs:element name="name" type="dimableIdentifierType"/>
      <!-- description contains reference manual level information about the function and
           options of a field -->
      <xs:element name="description" type="stringType" minOccurs="0"/>
      <!-- alternative specifications of the bit position of the field within the register -->
      <xs:choice minOccurs="1" maxOccurs="1">
        <!-- bit field described by lsb followed by msb tag -->
        <xs:group ref="bitRangeLsbMsbStyle"/>
        <!-- bit field described by bit offset relative to Bit0 + bit width of field -->
        <xs:group ref="bitRangeOffsetWidthStyle"/>
        <!-- bit field described by [<msb>:<lsb>] -->
        <xs:element name="bitRange" type="bitRangeType"/>
      </xs:choice>
      <!-- access describes the predefined permissions for the field. -->
      <xs:element name="access" type="accessType" minOccurs="0"/>
      <!-- predefined description of write side effects -->
      <xs:element name="modifiedWriteValues" type="modifiedWriteValuesType" minOccurs="0"/>
      <!-- writeContstraint specifies the subrange of allowed values -->
      <xs:element name="writeConstraint" type="writeConstraintType" minOccurs="0"/>
      <!-- readAction specifies the read side effects. -->
      <xs:element name="readAction" type="readActionType" minOccurs="0"/>
      <!-- enumeratedValues derivedFrom=<identifierType> -->
      <xs:element name="enumeratedValues" type="enumerationType" minOccurs="0" maxOccurs="2">
      </xs:element>
    </xs:sequence>
    <xs:attribute name="derivedFrom" type="dimableIdentifierType" use="optional"/>
  </xs:complexType>

As above part of CMSIS schema I see that derivedFrom is attribute of field, not enumeratedValues

[burrbull]

Hmm, You need read deeper CMSIS schema :p

            <field derivedFrom="PUPDR0">
              <name>PUPDR1</name>
              <description>Port x configuration bits (y =               0..15)</description>
              <bitOffset>2</bitOffset>
              <bitWidth>2</bitWidth>
            </field>

Deriving of whole field is independent question. You are right saying that this is better in this particular case.
But this doesn't give answer why svdconv can't find enumeratedValue. It doesn't say "whole field should be derived here", it says "DerivedFrom not found"

[KamilDuljas]

As I said above. Not found because enumerated value has not "derivedFrom" attribute in schema

[burrbull]

enumeratedValues has https://www.keil.com/pack/doc/CMSIS/SVD/html/elem_registers.html#elem_enumeratedValues

Oh. @adamgreig could you comment this?

stm32-rs/svd/cmsis-svd.xsd

Lines 23 to 30 in 371fc81

	This file is modified from version 1.3.6 for the stm32-rs project:
	https://github.com/stm32-rs/stm32-rs
	stm32-rs changes:
	- enumerationType now has enumeratedValue minOccurs=0, as otherwise
	a derivedFrom enumerationType does not validate
	Version 1.3.6:

[KamilDuljas]

Ah, ok. My mistake.

Perhaps you should extend naming such as
peripheral + register + field?

[KamilDuljas]

Ok I found some solution:
The name of enumeratedValues must be different than field name:

<field>
              <name>PUPDR0</name>
              <description>Port x configuration bits (y =               0..15)</description>
              <bitOffset>0</bitOffset>
              <bitWidth>2</bitWidth>
              <enumeratedValues>
                <name>PUPDR0A</name>
                <usage>read-write</usage>

and derivedFrom must be full "namespace":

<enumeratedValues derivedFrom="GPIOD.PUPDR.PUPDR0.PUPDR0A"/>

Otherwise It does not work. Maybe It is bug in svdconv or the next idocumentation issue and implicit assuming that the names must be different :)

[KamilDuljas]

I think that I open next issue on svdconv

[burrbull]

Thanks.

The name of enumeratedValues must be different than field name:

This should be easy to fix

and derivedFrom must be full "namespace":

but this could be problematic, especially during patching. The shorter the path, the less conflicts.

[KamilDuljas]

I know, full namespace sounds like bug... Or feature
:D

[burrbull]

I know, full namespace sounds like bug... Or feature :D

It is feature if we have ready unbugged SVD.
But if we need to change it, or even more copy parts from one to another then it's not funny anymore.

[KamilDuljas]

To tracking:
Open-CMSIS-Pack/devtools#815

[KamilDuljas]

@burrbull please refer to the proposed solution in Open-CMSIS-Pack/devtools#815

[thorstendb-ARM]

Hi, some comments:

• SVDConv is available as compiled for Windows, Linux, Mac, and as source distribution. See https://github.com/Open-CMSIS-Pack/devtools
• regarding derivedFrom:
  if field name and enumeratedValues container name are the same, it falls into a "this" trap, which fails afterwards, because the types do not match. See SvdItem.cpp, FindChildFromItem().
• regarding forward references:
  currently SVDConv does not support forward references. This is because derivedFrom can be executed to an object or it's children that have already been derived from another object, a dimed object, or both. SVDConv model stores and links original data and references to other objects (derivedFrom and dim), but currently forward references (which means, that derivedFrom is executed after reading the whole model) are not supported.

Regarding derivedFrom="PUPDR0.PUPDR0": The derive mechanism uses either:

• specify the name from current position going "down" the tree
• specify the full name from top of tree (peripherals container)
  If the object cannot be found on the current level, it is searched on top level (peripherals). Currently it is not possible to specify a path that goes up some levels and then down again.

If we would have no clusters (group of registers or other clusters) this would be easy (go up the number of dots). But as we have clusters with an unknown depth (clusters in clusters...) e.g. a path to a register can have an unknown depth from the current position. Consider:
ClusterA, containing RegisterA
Register B derivedFrom="ClusterA.RegisterA"

[burrbull]

@KamilDuljas with rust-embedded/svdtools#173 and #320 I've got

stm32f7x6.svd.patched.zip

svdconv shows:

Found 4 Error(s) and 295 Warning(s).