MCUX 11.0 map file error, incremental build not working

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MCUX 11.0 map file error, incremental build not working

2,031 Views
scottm
Senior Contributor II

I've just upgraded to MCUX 11.0 and I'm encountering two problems, not sure if they're related or not.  The first is that every time I compile I get three instances of "mismatched input '_estack' expecting RULE_HEX" in the 'Problems' view for the linker map file.  The folder the map file gets created in is excluded from the build and the project is being linked properly, so presumably this is a parser bug.  Here's the relevant bit of the map file:

                0x20000000                _estack = 0x20000000
                0x20000000                __stack = _estack
                0x20000000                __SP_INIT = _estack
                0x20000000                _vStackTop = _estack

The bigger problem is that it's apparently not doing incremental builds anymore.  If I hit control-B twice in a row, without changing any files or settings, it takes about 36 seconds to build the project.  I can't see what would have changed.

Any idea what's going on here?

Thanks,

Scott

0 Kudos
9 Replies

1,508 Views
lpcxpresso_supp
NXP Employee
NXP Employee

Your issue with map file awareness should be resolved with MCUXpresso IDE v11.0.1:

 

Regards,

MCUXpresso IDE Support

0 Kudos

1,508 Views
dmarks_ls
Senior Contributor I

I'm afraid that I'm encountering similar issues with my MAP file using MCUX v11.0.1.  Running a Kinetis K66 project with SDK 2.6.0.  After compiling, the IDE informs me that I've got 46,070 errors, all of them "Map File Problem" type, seem to be parsing failures.  I've attached my MAP file (anonymized).  And here's a (redacted/collapsed) portion of the errors I'm seeing.  I sorted the error locations, then scrolled to the bottom of the list.  Line 232 is the first error it detects.  I don't know if it's tripping over the C++ or what.  For what it's worth, my RT1050 C++ project doesn't exhibit this issue.

map_file_problems.png

0 Kudos

1,508 Views
lpcxpresso_supp
NXP Employee
NXP Employee

Indeed, the map file parser still has some limitations when it comes to dealing with C++ projects. We're looking into this. Meanwhile, if the parsing errors get into your way, you can follow Erich's guidelines on how to disable the map file 'awareness'.

Greetings,
MCUXpresso IDE Support

1,508 Views
lpcxpresso_supp
NXP Employee
NXP Employee

Thanks for sending this through. We will take a look.

In the meantime, if you wanted, you could delete the "errors" in the Problems view, and then right click on your map file within your project and select

  • Open with -> Generic Text Editor

This should cause it to be opened in future using the standard text editor instead of the Map File Editor, and prevent the errors being regenerated. Though obviously this will loose you the awareness feature for this file.

Regards,

MCUXpresso IDE Support

0 Kudos

1,508 Views
scottm
Senior Contributor II

Thanks, I'll do that.  The syntax highlighting is so slow that I don't think I'm going to want to keep that enabled anyway.  Or if you've got any tips on limiting how much useless junk gets thrown in the map file, I'm all ears.  I end up with thousands of lines that look like this:

 .group         0x00000000        0xc ./source/filter.o
 .group         0x00000000        0xc ./source/filter.o
 .group         0x00000000        0xc ./source/filter.o
 .group         0x00000000        0xc ./source/filter.o
 .group         0x00000000        0xc ./source/filter.o
 .group         0x00000000        0xc ./source/filter.o
 .group         0x00000000        0xc ./source/filter.o
 .group         0x00000000        0xc ./source/filter.o
 .group         0x00000000        0xc ./source/filter.o
 .group         0x00000000        0xc ./source/filter.o
 .group         0x00000000        0xc ./source/filter.o

As far as I can tell there's no useful information conveyed and I don't see any way to turn it off.

Thanks,

Scott

0 Kudos

1,508 Views
BlackNight
NXP Employee
NXP Employee

How to 'disable' it:

you can open the map file as normal text file:

pastedImage_1.png

This should speed up things for you.

If that helps (what I assume), you can make it fixed with the 'Other...' of above menu:

pastedImage_2.png

I hope this helps,

Erich

0 Kudos

1,508 Views
lpcxpresso_supp
NXP Employee
NXP Employee

We certainly haven't seen any issues with incremental builds to date with v11.0.0 here.

With regards to the map file "error", is there a chance that you could provide either the whole of your map file - or at least a larger snippet that gives us more context? And assuming that these symbols are being produced by your own linker script, could you give us the relevant section of that too?

[Note - this parser "error" is really just a warning that parser didn't recognise something in your file. It isn't stopping your project from building.]

Regards,

MCUXpresso IDE Support

0 Kudos

1,508 Views
scottm
Senior Contributor II

Here's the map file and linker configuration file.  Be warned, the map file really bogs down the IDE.

The linker script has some aliases like _estack, __stack, __SP_INIT, and _vStackTop because the project probably started out on CodeWarrior 6.x - or at least a pre-Eclipse version - and it's been through multiple SDKs and tool chains and a few versions of the startup code.

It looks to me like the parser just doesn't like a symbol being assigned to another symbol, and expects a literal hex address there.

Thanks,

Scott

0 Kudos

1,508 Views
scottm
Senior Contributor II

Ok, I think I've fixed the incremental build problem.  I found that my other projects were working normally and started comparing them.  For some reason, the refresh policy on this project was blank.  I had to add the project to the refresh policy and now that part seems OK.

The linker map is still throwing an error whenever I open it in the IDE, though, and the image info view still doesn't work.  This time I got "An internal error occurred while showing an internal error" along with "GC overhead limit exceeded".

Scott

0 Kudos