Minor: SVDConv: __VTOR_PRESENT generated for CM33

[simtind]

When generating headers from CM33 SVD files with no vtorpresent element, __VTOR_PRESENT value is generated as 0. According to the CMSIS Documentation CM33 devices should not have a __VTOR_PRESENT macro since a vtor is always available. When building with a CM4 __VTOR_PRESENT is not generated.

Reproduction file and resulting header attached, built using SVDConv 3.3.13 with command "svdconv adevicename.svd.txt --generate=header" . Source adevicename.svd.txt Result adevicename.h.txt

[JonatanAntoni]

Hi @simtind,

The macro __VTOR_PRESENT is used to distinguish whether the device support the VTOR register (1) or not (0 or undefined). You need to add <vtorPresent>true</vtorPresent> to your SVD file in order to get this macro defined to 1. Otherwise it defaults to 0.

Cheers, Jonatan

[simtind]

The variable should not be generated at all, as in Cortex-M4. Generating it for Cortex-M33 is an error.

[JonatanAntoni]

Hi @simtind,

please take a look to the core reference headers, like Device/ARM/ARMCM4/Include/ARMCM4.h for Cortex-M4 or Device/ARM/ARMCM33/Include/ARMCM33.h for Cortex-M33. Both have #define __VTOR_PRESENT 1U /* VTOR present */. The define is used later, e.g. during generic SystemInit to initialize the VTOR register if present.

Of course you are right that this define does not impact the definition of the SCB on CM3/4 nor on CM33 because VTOR is mandatory on these devices. Hence __VTOR_PRESENT should always be defined to 1 one those. If it is not defined its synonymous with 0, i.e. VTOR is not available. Generic software implementations relying on this define might fail to work.

Which error do you receive? I guess something else goes wrong.

Cheers, Jonatan

[simtind]

I do not explicitly get an error, but your tool is being inconsistent. Why does a Cortex-M4 NOT get __VTOR_PRESENT declared, while Cortex-M33 DOES get __VTOR_PRESENT declared when they both have a hardcoded value somewhere else? I can appreciate not wanting to change something that works, but it would be nice if SVDConv was consistent in this.

I also want to add that if the vtorpresent tag acts the way you indicate SVDConv is not in line with the SVD spec. Quoting from https://www.keil.com/pack/doc/CMSIS/SVD/html/elem_cpu.html :

Indicate whether the Vector Table Offset Register (VTOR) is implemented in Cortex-M0+ based devices. This tag is either set to true or false, 1 or 0. If not specified, then VTOR is assumed to be present.

[JonatanAntoni]

Hi @simtind,

fair point. That observation actually looks a bit weird to me. The define should always be in the generated header file reflecting the availability of VTOR register.

Defaulting to 1/true (rather than 0/false) on devices where VTOR is mandatory might be reasonable. But we should have it consistently for all devices. Let me check that in SVDConv. If you are authoring device header files please assure this define is set correctly, it should be 1 on CM33.

Cheers, Jonatan