.MEX file incompatible in MCUXpresso v11.6.0

[rnjdm]

After updating the MCUXpresso from v11.5.0 to v11.6.0 the .mex file is not opening anymore.

Says a message "Corrupted File or not Mex Format".

Since is a txt file is there any workaround to update it to be readable in the last release software?

[rnjdm]

Hi Erich, the "/" was used as an "inverted" signal for the label, since there were no warnings in the v11.5 we thought that it was fine. Thanks for this help, it worked. We will update labels to avoid this type of error.

[ErichStyger]

can you share your file (possibly the old and new version).

Beside of that: the .mex is only a cache file: all information is stored inside the source files.

So you can simply delete the .mex and open the config tools again: it will re-build the .mex based on the information in the .c files (YAML information) again.

I hope this helps,

Erich

[gertvb]

Erich,

Thanks for the info on just deleting the .mex file and it being recreated from info in the .c files!

My field laptop I use when working on Irrigation stuff is an old and very slow wind-up model, that has now survived the 'drop test' from being balanced on a ladder, as well as the 'hammer dropped unto it' test . . . So I dont want to take an expensive fast laptop into the field with me.

But with the laptop being slow it often complains about timeouts on pins.js when opening the .mex file when I open the pins configtool from within MCUXpresso, and then subsequently also not allowing me to update code after changing something on the configtools pins configuration.

Deleting the .mex file and recreating it when going into the pins config doesn't generate the problem, so I am now able to modify a pin configuration whilst not in the office, which helps tremendously!

Thanks Gert

[rnjdm]

Follows the .mex attached.

You can reproduce the error loading in version 11.6. If you open in 11.5 will run normally.

We did not create this .mex from a mcuxpresso project, is just a preview for a new project that was not coded yet and we are checking the compatibility of peripherals.

[ErichStyger]

Thanks for the file, and I can reproduce it on my side: I can load it in 11.5.1 and it fails in 11.6.0.

What I see in the .metadata/.log is the following

!ENTRY com.nxp.swtools.utils 4 0 2022-07-20 16:13:54.168
!MESSAGE Corrupted file or not MEX format MCUXpressoIDE_11.6.0_8187\workspace\MK22F51212_Project\UCV4-PinMux.mex
!STACK 0
javax.xml.stream.XMLStreamException: ParseError at [row,col]:[69,80]
Message: An invalid XML character (Unicode: 0x1f) was found in the value of attribute "label" and element is "pin_label".
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(Unknown Source)
at java.xml/com.sun.xml.internal.stream.XMLEventReaderImpl.nextEvent(Unknown Source)
at org.simpleframework.xml.stream.StreamReader.read(StreamReader.java:110)
at org.simpleframework.xml.stream.StreamReader.next(StreamReader.java:94)

I checked the labels, but cannot fine such a 0x1f (separator) in there.

I ping the IDE team if they could add some thoughts on this one.

Erich

[ErichStyger]

there is definitely something with the pin labels.

You could delete the content between the <pin_labels> .... </pin_labels>, and then it loads in 11.6.0.

You will loose the pin label information, but this is maybe ok for you.

I think one would have to check all the labels to find the one with the problem: I did not spot it right away.

[ErichStyger · Accepted solution]

Ok, using

https://www.soscisurvey.de/tools/view-chars.php

I have found several illegal separators in the file:

Removing the illegal separators, I can now load your file. Attached the fixed version.

I hope this helps,

Erich

[liborukropec]

Hello Ricardo, Erich,

Erich, thank you for quick help to the user.

it seems that one dependency used for serialization/deserialization has been changed between v11 and v12 and behaves strangely that weird (unicode) character is serialized without any issue but after that it cannot be deserialized. I have not found the root cause or hot fix for the moment. We'll try to address it in the next release. Definitely weird characters might break other tools (compilers, etc.) so if entered, the tool could provide some warning at least.

Regards,

Libor

[liborukropec]

Hello,

as it happens - once one submits a reply, immediately after the more precise information is found.

According to the XML specification https://www.w3.org/TR/REC-xml/#charsets the Unit Separator (0x1f) is not allowed in XML at all.

Char

::=

#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]

/* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */

So I doubt we can persuade any XML processor to accept 0x1f. So the only solution (fix in the future version) is to inform user about invalid character in the value before it is saved (and corrupted).

Regards,

Libor

[ErichStyger]

Hi Libor,

yes, the correct solution/fix is that the tool does not generate an invalid XML file.

Erich