MCUX 10.3.1 - How to fix not finding standard header files?

[dmarks_ls]

Odd thing that's happened that I haven't encountered before... I'm developing a new C project for a Kinetis K24, the project compiles, links, and debugs fine.  But the IDE has apparently lost track of where the standard header files are.  Example from one of my main header files:

This then leads to all sorts of annoyance, especially when viewing code suggestions:

Why can the IDE suddenly no longer find the standard header files?  Is there a simple way to investigate and fix this?  Thanks.

[BlackNight]

To follow up on this thread:

The IDE V11.0.0  (and later) have a context menu item (right click on the project main folder) which fixes the parser for any projects which expose this issue:

Tools > Fixup Parsers

I hope this helps,

Erich

[lpcxpresso_supp · Accepted solution]

We have managed to work out the cause of the "header files going missing" issue with the indexer. Unfortunately there isn't a real workaround for the existing MCUXpresso IDE releases, but we will be fixing the problem in the next MCUXpresso IDE release (expected late Q2). 

Regards,

MCUXpresso IDE Support

[dmarks_ls]

You'll want to reply to this thread and this thread as well, thanks.

[dmarks_ls]

Well, I'm glad you've identified the issue at least; since there's no workaround, presumably there's nothing I'm "doing wrong", so I'll just have to wait for 10.4.0 to come out.  Thanks for letting us know.

[BlackNight]

Hi David,

There has been a similar report here: MCUXpresso - how to set the default/system include paths 

This has been investigated by the IDE team and a fix for this will be available in the next update (probably a few weeks out).

Normally you should see the necessary include paths here:

If not present, you can add the following paths (depending on your toolchain) to the compiler include paths:

• C:\nxp\MCUXpressoIDE_10.3.1_2233\ide\plugins\com.nxp.mcuxpresso.tools.win32_10.3.0.201811011841\tools\redlib\include
• C:\nxp\MCUXpressoIDE_10.3.1_2233\ide\plugins\com.nxp.mcuxpresso.tools.win32_10.3.0.201811011841\tools\features\include

I hope this helps,

Erich

[dmarks_ls]

Well, you were almost onto something there.  You're right, those built-in paths were not showing up in my current (but still fairly new) project.  They ARE there in a brand spanking new project that I just created.  So I tried adding them to my existing project, and that caused my build to fail, because now some Redlib type definitions were conflicting with Newlib, mainly because (I think) Redlib defines int32's as int, while Newlib defines them as long.  (To be clear, my current project is Newlib because I need the malloc() thread safety hooks that NewlibNano was not compiled with, and because Redlib is not C++ compatible, so this C project uses Newlib to maintain compatibility with our libraries.)  So I swapped "arm-none-eabi" for "redlib" in the path above, and now it's back to building OK.  So clearly, even though it's not displayed as a built-in, the IDE is still using the Newlib include path to build the project.  And to be clear, I haven't been having any build failures, only indexer issues.

Unfortunately, this hasn't fixed the indexer issue.  I tried "Index / Rebuild" and "Index / Re-resolve unresolved includes" at multiple points, but the indexer remains ignorant of where those header files are, and keeps showing the orange squiggles.  So, no resolution there.  I don't know where the indexer draws its configuration from precisely, or if there's some way to inspect that.

[ZhangJennie]

Hi David Rodgers

Please check if you check enable indexer option. if still can't fix the issue, please create a new workspace and test your project in this new workspace.

Have a great day,
Jun Zhang

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[dmarks_ls]

Tried what you suggested, didn't work.  I already had "Enable indexer" checked, made sure that "use active build configuration" was selected.  So I created a new workspace from scratch, reloaded my code template and code formatter settings, pulled a fresh copy of my project from SVN, imported it into the workspace, and checked one of my header files... still shows orange question marks for all system include files.

So, what should I try next?

(To be clear, this is the first time I've encountered this issue.  I've developed many other projects over the last couple of years using MCUXpresso, and this is the first time that system includes have failed to resolve.  It's not even specific to 10.3.1... I have another workspace where I was doing some RT1050 development, and system include files are indexed just fine there.)

[ZhangJennie]

Hi David Rodgers,

Is this problem only in this specific project or a common issue for all project? If you create a new project with wizard, does it also have the same problem

If the problem is only in one project, please send your project here, thus we can check it directly.

Thanks,

Jun Zhang

[dmarks_ls]

The problem does not automatically apply to all projects within a given workspace.  However, once the problem occurs for a given project, it appears impossible to make it go away.

Here's exactly what I did to test this scenario out.

1) Made a brand new K24 project "k24_test", selected C, Newlib, all the drivers, mbedTLS, etc.

2) Added the MBEDTLS_CONFIG_FILE define to the preprocessor, since the project won't compile without it (seriously, how did NXP overlook that?).

3) Added our own "secret sauce" headers and libraries to the project, along with the include path, in case there was somehow something in one of those that was causing an issue.

4) Compiled the project successfully.  The #include <stdio.h> in the main source is OK.

5) Rebuilt the index, just for kicks.  No change, includes look good.

6) Cleaned the project and created an archive of the project in this state.

7) Started copying over a couple of things from my previous project into this new one to see if I could either trigger the problem or manage to completely reconstruct my old project with no issues.

8) Somehow managed to trigger the issue - #include <stdio.h> now appears with a question mark and orange squiggles.

9) Renamed this project "k24_test_indexer_failed".  #include <stdio.h> still bad.

10) Deleted our "secret sauce" from the project, which now only contains NXP SDK code.  #include <stdio.h> still bad.

11) Closed the bad project, unarchived the "good" project, and re-imported it into the workspace

12) The "good" project now also appears bad, #include <stdio.h> is flagged in orange.

It's #12 that I really don't get... if it were something endemic to the project, I don't see why the indexer would suddenly fail to index standard headers just because I unarchived and re-imported the project.

Anyway, you wanted an example project where the indexer has failed.  Ah, apparently I have to use the "Advanced Editor" to include an attachment.  See attached.  I've added comments in the main source file to be clear on exactly what I'm seeing.