Version mismatch in Config Tools mex xml?

[MichaelV]

Hi,

I just created a simple mex file for processor iMX6 Quad in Config Tools v13 and opened the xml. The xml still shows it is using the v12 xsd, but the processor version has version 13 in the XML. Is this correct?

<?xml version="1.0" encoding= "UTF-8" ?>
<configuration name="MCIMX6QxxVT" xsi:schemaLocation="http://mcuxpresso.nxp.com/XSD/mex_configuration_12 http://mcuxpresso.nxp.com/XSD/mex_configuration_12.xsd" uuid="0e8449ae-0ebd-478a-b89f-cdc2be29e423" version="12" xmlns="http://mcuxpresso.nxp.com/XSD/mex_configuration_12" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <common>
      <processor>MCIMX6QxxVT</processor>
      <package>MCIMX6Q7CVT08AD</package>
      <mcu_data>i_mx_1_0</mcu_data>
      <cores selected="ca9_0">
         <core name="Cortex-A9 (Core #0)" id="ca9_0" description="ARM Cortex-A9 MPCore platform with TrustZone and NEON MPE Co-processor Core #0"/>
         <core name="Cortex-A9 (Core #1)" id="ca9_1" description="ARM Cortex-A9 MPCore platform with TrustZone and NEON MPE Co-processor Core #1"/>
         <core name="Cortex-A9 (Core #2)" id="ca9_2" description="ARM Cortex-A9 MPCore platform with TrustZone and NEON MPE Co-processor Core #2"/>
         <core name="Cortex-A9 (Core #3)" id="ca9_3" description="ARM Cortex-A9 MPCore platform with TrustZone and NEON MPE Co-processor Core #3"/>
      </cores>
      <description></description>
   </common>
   <preferences>
      <validate_boot_init_only>true</validate_boot_init_only>
      <generate_extended_information>false</generate_extended_information>
      <generate_code_modified_registers_only>false</generate_code_modified_registers_only>
      <update_include_paths>true</update_include_paths>
      <generate_registers_defines>false</generate_registers_defines>
   </preferences>
   <tools>
      <pins name="Pins" version="13.0" enabled="true" update_project_code="true">
         <pins_profile>
            <processor_version>13.0.0</processor_version>
            <power_domains/>
         </pins_profile>

[liborukropec]

Hello Michael,

you are correct, the mex should point to the xsd v13, we'll fix it into the next release. It should not have impact on the tool itself, only external usage, sorry for any inconvenience.

Regards,

Libor

[MichaelV]

Also, when loading either the v12 xsd or the v13 xsd into the XmlSerializer class in C#, a System.InvalidOperationException is thrown:

configuration.configuration_13.configuration mexConfiguration;
Type configurationType = typeof(configuration.configuration_13.configuration);
// Serialize the configuration file (mex)
XmlSerializer ser = new XmlSerializer(configurationType);

System.InvalidOperationException
  HResult=0x80131509
  Message=Unable to generate a temporary class (result=1).
error CS0030: Cannot convert type 'GenBoardFile.configuration.configuration_13.configurationToolsDcdDcdx_configurationsDcdx_configurationCommand_groupsCommand_groupCommandRegistersRegister[]' to 'GenBoardFile.configuration.configuration_13.configurationToolsDcdDcdx_configurationsDcdx_configurationCommand_groupsCommand_groupCommandRegistersRegister'
error CS0030: Cannot convert type 'GenBoardFile.configuration.configuration_13.configurationToolsDcdDcdx_configurationsDcdx_configurationCommand_groupsCommand_groupCommandRegistersRegister[]' to 'GenBoardFile.configuration.configuration_13.configurationToolsDcdDcdx_configurationsDcdx_configurationCommand_groupsCommand_groupCommandRegistersRegister'
error CS0029: Cannot implicitly convert type 'GenBoardFile.configuration.configuration_13.configurationToolsDcdDcdx_configurationsDcdx_configurationCommand_groupsCommand_groupCommandRegistersRegister' to 'GenBoardFile.configuration.configuration_13.configurationToolsDcdDcdx_configurationsDcdx_configurationCommand_groupsCommand_groupCommandRegistersRegister[]'
error CS0029: Cannot implicitly convert type 'GenBoardFile.configuration.configuration_13.configurationToolsDcdDcdx_configurationsDcdx_configurationCommand_groupsCommand_groupCommandRegistersRegister' to 'GenBoardFile.configuration.configuration_13.configurationToolsDcdDcdx_configurationsDcdx_configurationCommand_groupsCommand_groupCommandRegistersRegister[]'

  Source=System.Xml

This is of course besides the still existing circular definition due to periphs_setting_list (but I can comment that out in the xsd).

This must be because of some problem in the xml. Any idea?

If I comment out everything to do with configurationToolsDcd and configurationToolsDcdx in the .cs file, my tool works.

We use the Config Tool xml files to generate board header files for our BSP, but with every new version of the Config Tool we run into more and more issues with the xsd/xml.

[liborukropec]

Hello Michael,

regarding the recursion, the XSD should allow this, so this should not be a problem. To be honest we use only Java based validation, I cannot comment XmlSerializer in C#.

Anyway, I can see some issue with the XSD and the MEX for MCIMX6QxxVT, I'll forward to the team and later on we'll post an answer here.

Thank you,

Libor

[MichaelV]

@liborukropec,

It would be very good if you can get the XSD formatted in such a way that this command succeeds:

"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\x64\xsd.exe" mex_configuration_13.xsd /c

And then in a C# app, use the generated .cs as follows:

configuration.configuration_13.configuration mexConfiguration;
Type configurationType = typeof(configuration.configuration_13.configuration);
// Serialize the configuration file (mex)
XmlSerializer ser = new XmlSerializer(configurationType);

This way you'd quickly discover any issues in the XSD (and it would prevent us from having to debug & fix your XSD with every new version of the Config Tool).