Just Upgraded to MCUXpresso 11.4.0 and Error loading in .mex file

[myke_predko]

Hey NXPers,

I just upgraded to MCUXpresso 11.4.0 on Linux and when I try to load a project or use the Wizards, I get the pop up:

Error during opening configuration <ProjectName>/mex:

Communications error.  Check the connectivity to the Internet and repeat again.  

I'm not sure what this means as clearly the Internet connection is fine (or you wouldn't be seeing this).  It's the same for all projects and .mex files.  

I've reverted back to 11.3.1 and things seem to be working fine there.

Comments?

I'm also sharing this with the Kinetis forum.  

[myke_predko]

@lpcxpresso_supp & @liborukropec 

Okay, I think I figured out the problem - source files aren't being the checked the same way as include files.  

For example, if I put in "#include "nothing.h" in a source file and a .h, I get the results:

I noticed that syntax errors were no longer caught in the source editor like:

I haven't changed anything in MCUXpresso's IDE or the project preferences.  

This wasn't an issue in 11.3.1.  

Could you please look into this?  

[myke_predko]

@lpcxpresso_supp & @liborukropec 

One more datapoint.  

When I built the code in the last example (#include "nothing.h" in a .c and a .h), there is an error generated by the non-existent file in the .h file but no error in the .c.  

I consider this to be a very signicant problem with the operation of MCUXpresso IDE and how the compilers work with different files types.  

Sorry for adding to your workload, but these issues need to be addressed immediately.  

myke

[converse]

Suggest you create a simple project that can be used to demonstrate and reproduce the issues you are reporting. Then export the project and attach it to this thread. Without something to show the problem, it is almost impossible to reproduce, based purely on your description and screenshots.

[myke_predko]

@converse 

That was a good suggestion with a new datapoint.  Thank you.  

@lpcxpresso_supp & @liborukropec  I followed the suggestion by @converse and created a small project (attached) to see if I can replicate the problem.  I did the "hello world" example code with what I thought would be problems.  

Interestingly enough, it works perfectly which is the opposite to my main project.  

My main project was created by copying in the source files (.c & .h) along with the .mex file from a project created by MCUXpresso 11.3.1.  NOTHING other than .c, .h and .mex was copied from the previous project.  

Ideas as to what's happening here?

Thanx.

[lpcxpresso_supp]

At first sight, the indexer does not successfully parse the source file you refer to. I noted that you're modifying a relatively large source file (2k+ lines). Maybe this is what's causing the issue? Not sure if there's such a (low) limit though. Would you please try the same use case in other source files and let us know if that works as expected? Anyway, I'd also expect the same behavior in IDE v11.3.x.

You might also want to check whether the "unresolved inclusion" is not reported at all or it's just not shown in the IDE's views (Source and Problems). To do this, right-click the source file with the invalid header inclusion => Index => Create Parser Log File. Then check "Scanner problems" section.

As a side note, CDT comes with a code analysis tool (Codan) and with the Indexer. They both inject markers and they both can be controlled at workspace/project level (Window => Preferences => C/C++ => Code Analysis / Indexer, or via project's properties => C/C++ General => Code Analysis / Indexer / Paths and Symbols). Maybe check these as well.

Greetings,
MCUXpresso IDE Support

[myke_predko]

@lpcxpresso_supp 

Can I ask what happened to console PRINTFs in Semihosting debugging?  

I use them quite a bit for monitoring operation during development - how do I get them back?  I noticed the change in SDK_DEBUGCONSOLE default being set to 1 rather than 0, but I thought setting it to 0 would allow things to run as expected.  

I know that Semihosting is out of style but I really don't want to change to another approach at this point of product development.

Thanx - hopefully there's a simple answer here.  

[lpcxpresso_supp]

The easy part first... 

Can I ask what happened to console PRINTFs in Semihosting debugging?

Decision to move from Semihosting to UART was mostly driven by some factors like consistence with other IDEs, performance and a preference towards UART coming from various directions. Sticking with Semihosting is easy - simply make sure it is selected accordingly during New / Import Project wizards. You can also make the switch by changing the runtime library and the define you mentioned. 

Regarding the indexer issues and the note below, was the log obtained while having the unresolved inclusion in that source file?

I did generate a log file (attached) and sections headed with "unresolved inclusion" and "scanner problems" are not present.  The source file compiles without errors or warnings.  

Also, it's worth disabling the setting highlighted in the screenshot below and see if it has any effect in your situation. Please report back the result. Meanwhile, we'll try to reproduce it on our side before jumping to NDAs.

Greetings,
MCUXpresso IDE Support

[myke_predko]

@lpcxpresso_supp 

You're two for two this morning.  

I made the Library change in the "Project Settings" and I see all my debugging information - thank you!

Now, when I create a new project, I should select "Semihost" for the "SDK Debug Console" as shown here:

I clicked off the "Disable editor live parsing" and everything appeared as expected:

I see in the box above, "Enable scalability mode when the number of lines in the file is more than: 5000" - "scrTask.c" is 5,089 lines long.  I just checked the size when I first created the project (from the previous project) and it was 5,019 lines long.  

Thank you very much for sticking with me.  

[ErichStyger]

Hi @myke_predko ,

trying to catch up ....

I see in the box above, "Enable scalability mode when the number of lines in the file is more than: 5000" - "scrTask.c" is 5,089 lines long. I just checked the size when I first created the project (from the previous project) and it was 5,019 lines long.

I see you have found the setting. I recommend to increase it maybe to 10k or so, as FreeRTOS task.c is above 5k too.

The other hint: this is all about the 'Indexer', so it might make sense for you to re-run it in case you think it is out of sync: there is a context menu on the project (Index > Rebuild) for this. Additionally depending on the complexity of your projects I recommend to disable the 'heurisitics', see https://mcuoneclipse.com/2012/03/20/fixing-the-eclipse-index/  and for power users: https://mcuoneclipse.com/2021/01/10/eclipse-indexer-debug-tips/

I hope this helps,

Erich

[myke_predko]

Hey @ErichStyger 

The 5k file source file, as I noted elsewhere is a tokenized script file processor for the Jade Robot.  It has to process 66 token types as well as 301 API calls with the main execution requirement being speed along with execution quality.  It's jump table based to ensure minimal and consistent execution times and I was going to say that it has been written with minimal common method calls but that's inaccurate as there are only two areas where code is repeated and could be put into common code repositories and they're about 50 lines each.  

Is there a better way to format the code?  I've found that even using inline methods has some additional overhead.  I have seen this functionality done using macros, but that makes debugging difficult as well as obfuscating the readability of the code.  In case you're curious, I am using standard SDK API and FreeRTOS methods and calls - I'm not "optimizing" them for my application as I know that's guaranteed to be a disaster.  

Honestly, if you have a better way of organizing the code, I'd love to hear about it; it's been through multiple code reviews and evaluations with the speed requirement really making it difficult to break up the functionality into smaller pieces.  

[ErichStyger]

Hi @myke_predko,

Is there a better way to format the code?

That '1k' rule is a rule of thumb, and as for every rule or guidelines there are exceptions. It is usually hard to apply the rule for generated code because no real control over it, and the line 'limit' is kind of arbitrary too. What we have done in a few projects is working with huge 'data files in source form': think about bitmap data in hexadecimal form. We did them split up into some chunks, placing them in external files which then get included by #include in to the main file, just to keep things organized. That approach probably won't fit for your case anyway.

I hope this helps,

Erich

[myke_predko]

@lpcxpresso_supp 

As I indicated before, I looked at the other .c files in the project and they are showing the mark ups/other colours as expected.  

I did generate a log file (attached) and sections headed with "unresolved inclusion" and "scanner problems" are not present.  The source file compiles without errors or warnings.  

I took a look at the suggested preferences and couldn't see anything that jumped out at me.  As I've indicated that other .c files seem to work as expected.  

Now, the "scrTask.c" file is just over 5k lines in length - I'm guessing that it is running over some kind of line limit for the automatic mark up features.  I am not able to share this file with you without an NDA in place.  

What are our next steps?

[ErichStyger]

Hi @myke_predko ,

I apologize for jumping in here late (have been busy with preparing the new university course material).

Now, the "scrTask.c" file is just over 5k lines in length - I'm guessing that it is running over some kind of line limit for the automatic mark up features.

Yes, there is a default limitation of 5k lines for the indexer in Eclipse. You might have seen my article about it here: https://mcuoneclipse.com/2020/10/31/freertos-and-eclipse-indexer-for-5k-lines-source-files/

That setting is the default workspace setting in Eclipse as long as I can think of. The reason is to avoid slowing down the background Eclipse process to parse the files. If 5k is reasonable or not can debatable. My rule of thumb is that if a source file exceeds 1k it should require refactoring. But for generated files that rule might not apply.

Anyway you could increase that setting (I usually have it at 10k) and you should be fine.

I hope this helps,

Erich

[myke_predko]

@lpcxpresso_supp 

Thank you for the reply - sorry I've taken so long to get back to you; it's been a very busy day.  

Yes, it seems to be only this file - it's about 3,500 lines long and all the other files in the project are 500 or less.  This file is an instruction token parser that's been ported from previous products so it will be modified with new tokens but won't be rewritten.  

I'll look at your other two points and report back as to what I find.  I should point out that this was not an issue with 11.3.1 (I noticed it basically the first time I opened it from the .c file in the editor) and it definitely works in CodeWarrior (where the code came from originally).  

I'm surprised that there is a line length/size issue here - maybe when I look into the preferences/options something will jump out at me.  

Thanx again and I'll be following up with you.  

[converse]

So, is it the generated files that have the problem? Are they being placed into directories that are excluded from the build? Or excluded from indexing?

[myke_predko]

@converse 

Neither.  

They are source files that I created in earlier projects and copied into the "source" folder. 

[myke_predko]

Hey @lpcxpresso_supp & @liborukropec 

I just noticed that the colour change of structure elements and enums in the editor doesn't seem to be working in 11.4.0.  What's strange is that it comes up in the same (.h) file as it is defined, but not in a source (.c) file that access it.  You can see the issue in the marked up screenshot below:

I'd appreciate it if you could you look into this?

[liborukropec]

Hello Myke,

I'm really curious how did you 3 hours ago upgraded to MCUXpresso IDE 11.4.0, when it was announced just 2 hours ago

The data for MCUXpresso Config Tools v10 (also present in the MCUXpresso IDE 11.4.0) are being published right now and it will be finished within 24 hours.

If the problem persist after 24 hours, provide here the content of the <workspace>/.metadata/.log file.

Regards,

Libor

[myke_predko]

@liborukropec 

I think you're asking the wrong person how I upgraded when I received the attached email at 11:07AM EDT.  It's not like I followed any special links, after seeing the email at around 2:15PM EDT I Googled "mcuxpresso download" and started the download from the NXP link that came up - I should note that I had to login to be able to start the download.  According to the .deb.bin file information, the download was complete at 2:27:37PM EDT and I installed it immediately afterwards .  I guess I took 20 minutes to verify that the problem was with 11.4.0 along with reverting to 11.3.1 to ensure that none of my project files got trashed or were the original problem and wrote the email.  I figured NXP would want to know ASAP that there was a problem.  

This is the second time in two consecutive MCUXpresso releases where I have found and notified NXP of very obvious problems that escaped your release testing processes.  So, rather than ask me to try again in 24 hours and provide you with proof that there's still a problem - get your tools team to fix the problem, have them demonstrate to you that it's fixed as well as have implemented a process that prevents problems like this escaping and tell everybody here when it's done.  

I'm running Ubuntu 20.04 LTS in case somebody asks.  

[liborukropec · Accepted solution]

Hello Myke,

I missed the email notification and I saw only the Community announcement, my fault.

I figured NXP would want to know ASAP that there was a problem.

Thank you for reporting it.

... and tell everybody here when it's done.

It is done, data available for Config Tools v10 in IDE 11.4.0

Sorry for any inconvenience,

Libor