Garbage in MCUXpresso output, MAC OS X

[iancull]

I've been using the MAC version of MCUXpresso for a few months now with a new K22F project; I noticed today that the end of my compiled code has garbage nonsense in it, looks sometimes like source code! I just now used objcopy to convert the axf output file to lst format ("arm-none-eabi-objdump -S "${BuildArtifactFileName}" > "${BuildArtifactFileBaseName}.lst"") and the end of the file has sections like attached.

The screenshot shows "DRIVEROOT" in the listing, which is defined as a one character string:

const TCHAR DRIVEROOT[] = "/";

So it looks like the compiler is leaving heaps of junk after the definition; it's hard to be sure but maybe there's junk at the end of the "last" constant string in any module - although it looks like the order of constant strings isn't the same as source code so I can't be sure.

It looks like it's not just constant strings either; the final item in the listing is "__num_Ciob_streams" which doesn't exist in any source code.

Anyone got any ideas why this is happening, compiler / linker settings to make this issue go away? I've never seen it in my Windows MCUXpresso projects, though that's no proof that this is a MAC only issue.

[ErichStyger]

Hi @iancull ,

you are very likely using these strings in things like printf() or in similar things inside your application, either directly or indirectly e.g. in libraries. You need to search for these strings in your source code to find where they are used.

Erich

[iancull]

I'm wondering now ... is it just the listing file that's confusing? It's labeling lots of separate text all as "DRIVEROOT" rather than labeling each text separately?

I see those can be the various PRINTF strings I have - from multiple files, just all collected unlabeled at the end of the listing?

[ErichStyger]

Hi @iancull ,

This is not 'garbage' but are string constants. It looks your are compiling your code in 'DEBUG' mode with asserts enabled.

What you see are string constants which are used/needed for the code executed. If you have asserts enabled, this leads to extra constants with the asserts expressions and the source file names as this is used for the asserts.

I touch on that subject in Tutorial: How to Optimize Code and RAM Size | MCU on Eclipse and as well in Dealing with Code Size in Kinetis SDK v2.x Projects | MCU on Eclipse.

You might have a read at Solved: McuxPresso Binary file - NXP Community too.

I hope this helps,

Erich

[iancull]

Thanks, Erich.

It's true that the assert/debug had some effect which I'd not realized; I set NDEBUG and that reduced code by 1800bytes (about 4%) but it made no difference to the "garbage" hanging around at the end of defined strings - the listing file still shows "DRIVEROOT" as occupying >400bytes even though the string is defined as just one character (plus the 0 end marker)!

[converse]

From the look of it, DRIVEROOT is just the last symbol in the file. Everything else comes after it, but has no symbol information, so it appears 'under' DRIVEROOT.