Open KamilDuljas opened 1 year ago
Hi,
enumeratedValue name must be different than parent, in this case, different than field name.
The derive mechanism is using an internal "this" detection (where current item name equals derive name) before searching through children, but as the types do not match this throws an error. Will have a look at this. Currently please use a different name for the enum container.
Must be used full qualified name means GPIOD.PUPDR.PUPDR0.PUPDR0A
The derive mechanism uses either:
What about deriving the whole field? Or using dim?
typedef struct { /*!< GPIOD Structure */
__IM uint32_t RESERVED[3];
union {
__IOM uint32_t PUPDR; /*!< GPIO port pull-up/pull-down register */
struct {
__IOM uint32_t PUPDR0 : 2; /*!< Port x configuration bits (y = 0..15) */
__IOM uint32_t PUPDR1 : 2; /*!< Port x configuration bits (y = 0..15) */
__IOM uint32_t PUPDR2 : 2; /*!< Port x configuration bits (y = 0..15) */
__IOM uint32_t PUPDR3 : 2; /*!< Port x configuration bits (y = 0..15) */
uint32_t : 24;
} PUPDR_b;
} ;
} GPIOD_Type; /*!< Size = 16 (0x10) */
SVD file:
<?xml version="1.0" encoding="utf-8" standalone="no"?>
<device schemaVersion="1.1" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xs:noNamespaceSchemaLocation="CMSIS-SVD_Schema_1_1.xsd">
<name>Test</name>
<version>1.5</version>
<description>est</description>
<addressUnitBits>8</addressUnitBits>
<width>32</width>
<size>0x20</size>
<resetValue>0x0</resetValue>
<resetMask>0xFFFFFFFF</resetMask>
<cpu>
<name>CM4</name>
<revision>r1p5</revision>
<endian>little</endian>
<fpuPresent>true</fpuPresent>
<fpuDP>0</fpuDP>
<nvicPrioBits>4</nvicPrioBits>
<deviceNumInterrupts>20</deviceNumInterrupts>
</cpu>
<peripherals>
<peripheral>
<name>GPIOD</name>
<description>Test peripheral</description>
<baseAddress>0x40001000</baseAddress>
<interrupt>
<name>PUP</name>
<description>PUP Interrupt</description>
<value>2</value>
</interrupt>
<addressBlock>
<offset>0x0</offset>
<size>0x400</size>
<usage>registers</usage>
</addressBlock>
<registers>
<register>
<name>PUPDR</name>
<displayName>PUPDR</displayName>
<description>GPIO port pull-up/pull-down register</description>
<addressOffset>0xC</addressOffset>
<size>0x20</size>
<access>read-write</access>
<resetValue>0x00000000</resetValue>
<fields>
<field>
<name>PUPDR%s</name>
<dim>4</dim>
<dimIncrement>2</dimIncrement>
<description>Port x configuration bits (y = 0..15)</description>
<bitOffset>0</bitOffset>
<bitWidth>2</bitWidth>
<enumeratedValues>
<name>PUPDR0</name>
<usage>read-write</usage>
<enumeratedValue>
<name>Floating</name>
<description>No pull-up, pull-down</description>
<value>0</value>
</enumeratedValue>
<enumeratedValue>
<name>PullUp</name>
<description>Pull-up</description>
<value>1</value>
</enumeratedValue>
<enumeratedValue>
<name>PullDown</name>
<description>Pull-down</description>
<value>2</value>
</enumeratedValue>
</enumeratedValues>
</field>
</fields>
</register>
</registers>
</peripheral>
</peripherals>
</device>
Tested "detect designated SVD level" to check "this" compare inside FindChildFromItem(), this is more complex than thought when <cluster>
comes into place.
Task to be done later as there is a workaround.
Hi, during resolving simillar issue created yesterday, I tried to fix errors return by svdconv. One of them points incorrect derivation. Example:
Error M206: DerivedFrom not found: 'PUPDR0.PUPDR0'
After few attempts I found solution that consist in two restrictions:
In related to ad.1 - The limitation is not mentioned in the documentation In related to ad.2 - It is expected behavior?
Example that works: