MCT 7.0 - MCT refuses to open for new project

[dmarks_ls]

I've just created a new RT1064 project.  When creating the project, I selected the CVJ5A variant of the RT1064.  My project builds and links correctly.  Now I want to customize the pins and clocks for my project.  But MCT is refusing to generate a MEX file or even let me open the current project in MCT 7.0.

So I have the MCT view open:

You can see at the top that no project is currently open in MCT, even though I have my project open in the Develop perspective.  If I use the "<Select Project>" dropdown to select my project, I get a progress dialog that pops up for a few seconds, then completes and disappears, and I'm left with the same view, no pins, no project open.  If from the Project Explorer (which I have open at the bottom right) I right-click the project, then select "MCUXpresso Config Tools", then pick any option (let's say "Open Pins"), the same progress dialog opens and runs for a few seconds, but instead of it disappearing, I then get this:

My first question on seeing this is "why?".  When I created my project, I specifically picked the CVJ5A variant of the chip.  Why would the DCD component be stuck on the DVL6A variant?  My second question is, "where are these settings buried?"  I haven't been able to decipher that (more below on that).

OK, so I tried instead importing settings from a similar, previous RT1060 project.  But of course, MCT won't let you import settings unless you already have the project open in MCT:

OK, maybe there are some project settings I'm missing.  So I look in my project properties:

Well, that's no damned help.  So I look at my MCU settings:

Nothing variant-specific, just the "A" revision of the RT1064.  OK, maybe MCT is reading existing source files to determine what MCU is being used for each of the components.  So I do two searches, one for the string "DVL", the other for "CVJ".

Bizarrely, there's direct mentions of the DVL package in the clock config and pin mux files, but no special mention of the CVJ package.  And yet, MCT is convinced that my clocks configuration is tied to the CVJ5A variant, and since that doesn't match the DCDx module's selection(?) of the DVL6A variant, MCT simply won't open.

So... how do I fix this?  Why does this tool exist in this state in the first place?  This is yet another incredibly frustrating MCUx bug that's preventing me from getting my job done and requiring me to take additional time to write up yet another seeming defect report.

Please tell me how to properly configure MCT to open the pins tool for my RT1064 project, thank you.

David R.

[dmarks_ls]

So, I managed (somehow) to figure out how to open the pins tool, except it makes no damn sense?  As you can see from the above text search, pin_mux.c and clock_config.c each call out the "DVL6A" variant.  Here's the relevant source from clock_config.c:

/* TEXT BELOW IS USED AS SETTING FOR TOOLS *************************************
!!GlobalInfo
product: Clocks v5.0
processor: MIMXRT1064xxxxA
package_id: MIMXRT1064DVL6A
mcu_data: ksdk2_0
processor_version: 0.0.0
board: MIMXRT1064-EVK
 * BE CAREFUL MODIFYING THIS COMMENT - IT IS YAML SETTINGS FOR TOOLS **********/‍‍‍‍‍‍‍‍‍

So remember from earlier that according to MCT, it thinks the Clocks tool is using the CVJ5A variant, while DCD is using the DVL6A component:

So, just for giggles, I changed the text of line 5 above to read:

package_id: MIMXRT1064CVJ5A‍

I modified pin_mux.c in the same way.  Then I tried opening the pins perspective again... and what do you know, the pins perspective finally opens.  If I switch to Clocks, I can see my clocks.  So it's working again.

To help narrow down exactly what was occurring, I closed MCUX, reverted clock_config.c and pin_mux.c to their original form, and deleted the MEX file that was generated.  I then re-opened MCUX and tried re-opening the pins perspective, and now it was once again broken, either silent failure when selecting the project or an error dialog if I pick "Open Pins".  Next, I changed only clock_config.c, and tried to open the pins or clocks perspective, and it still failed.  So I closed MCUX, reverted clock_config.c to the original, and modified pin_mux.c to mention the CVJ5A part.  And this time, I get a newer, more exciting error dialog:

What's going on?  My clock_config.c file contains a DVL6A reference, while pin_mux.c contains a CVJ5A reference.  And yet somehow it thinks that the Clocks are set for CVJ5A and the Pins are set for DVL6A?

So, making sure I can reproduce my earlier results, I then modify clock_config.c to reference the CVJ5A part.  And for whatever reason, that works.  Apparently both pin_mux.c and clock_config.c have to be set to the CVJ5A part.  And it's clearly reading the data from the C source files, as I've got all the different functional groups listed for the different pins.

Why are your error messages inaccurate?  Why do I have to edit these by hand?  Can you please shed some light on this?  What do you consider to be the correct solution to this issue?

David R.

[liborukropec · Accepted solution]

Hello David,

you correctly realized that the problem is in the *.c files and the respective YAML parts with the package. It seems as an error in the SDK package and their example(s), examples should not contain the package information in them. Config Tools then will get the package settings from IDE. So workaround is to delete all lines with "package_id: <package>" after importing the example - before opening config tools.

Long story: The YAML sections are used only once during importing the settings from sources, because of no MEX file. For this purpose the package should not be the there in order allow users to change the package in the wizard. After the MEX file is created, only settings from this file is read/used.

Once you start using Config Tools and generate sources, the selected package is stored there (in YAML) and it is correct - in case you lost MEX file, or send to someone only the *.c files without MEX, the other party can restore the settings precisely, including the package. And of course the information about the processor must be consistent - during loading all stuff one config cannot say we are "bird" and second config to claim we are "fish".

And regarding the error message - I admit it is not too much explanatory.

Regards,

Libor

[dmarks_ls]

Hi Libor,

I consider this to be symptomatic of inadequate testing performed at NXP prior to release.  It is a reasonable use case for a customer to create a project based on a variant of the processor (e.g. CVJ5A) different from what appears on the EVK (e.g. DVL6A), and then open the Config Tools to configure the pins and clocks.  You've already identified a "workaround" for this issue (removing package identifiers from the provided board files), one that would best be implemented by NXP in the deployed SDKs.  I'm a little frustrated with the seeming attitude that "if it works for one example, release it".  This to my mind was at the core of the issue I found with the MMC stack on the RT1050; the caching issue was never discovered by NXP because testing was only performed on an EVK using internal SRAM.  If testing had been done using SDRAM memory, NXP would have discovered the issue much earlier in development, hopefully before SDK release.

Also regarding the error message - it's not only that it's not explanatory, it's simply wrong.  When I got the dialog showing two part conflicts (DCDx vs. Clocks, and Pins vs. Clock), the state of the pin_mux.c and clock_config.c files was that pin_mux.c had

package_id: MIMXRT1064CVJ5A‍‍

while clock_config.c had

package_id: MIMXRT1064DVL6A‍‍

And yet, the error dialog stated that the pins were using "DVL6A" and the Clocks were using "CVJ5A".  That's backwards from the C source files it was reading from.  So why did changing the part selection in clock_config.c suddenly fix the apparent part selection for DCDx and Pins?  Please try this yourself: create a new RT1064 project, select the CVJ5A variant, try to open the Pins tool, then fix the "package_id" for just pin_mux.c (setting it to CVJ5A), and try to open the Pins tool again.  Hopefully you'll get the same dialog that I do, and then you can figure out why the error dialog is providing incorrect information.

David R.

[liborukropec]

Hi David,

cannot comment testing as I'm not part of the testing team. Please let me correct my previous not exact answer.

There are two cases for creating projects in IDE with SDK:

Importing a SDK example - where the package cannot be changed and here it should work as expected. The example was tested for given board/settings.

Creating NEW project - please note that if you change the package (for your custom board), the recommended flow is not using 'Default board files', which in general will be incorrect for your particular board pin routing. Also the New Project Wizard shows this as an warning message:

Recommended way is to select "Empty board files" for this case.

Your problem seems to be reproducible for MCUs with DCD configuration.

I can see two bugs

1. It seems the error message has swapped package between reported tools
2. The DCD tool complains about the package and it shouldn't. At this moment I cannot say if problem is the evkmimxrt1064_sdram_ini_dcd.c (part of the SDK package) or the tool itself.

At this moment I can recommend:

1. either use Empty board file
2. or if you insist on using board files for EVK, in the wizard do not change the package, leave it in default state and open the config tool. This will create MEX and initializes all tools. Then using popup menu in "Project Explorer" you can change the package:
   

Regards,

Libor

[dmarks_ls]

Hi Libor,

I'm glad you were able to reproduce the issue.  Thanks for providing clear workaround steps.

David R.