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
Your issue with map file awareness should be resolved with MCUXpresso IDE v11.0.1:
Regards,
MCUXpresso IDE Support
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.
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
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
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
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
How to 'disable' it:
you can open the map file as normal text file:
This should speed up things for you.
If that helps (what I assume), you can make it fixed with the 'Other...' of above menu:
I hope this helps,
Erich
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
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
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