Problem with mbd_s32k.tlc and mbd_s32k14.tlc, using S32K144EVB-Q100

[neffnan]

I have an extremely simple model, extracted from NXP MBDT GPIO example: a state machine toggling on and off, and a signal to a LED. I change the color of the LED between successful loads to confirm that a new executable has loaded in case I miss the brief timeout. A zip of the current, working version is attached.

The example model builds, deploys, and starts just fine. I copied the state machine and GPIO block into a new model, and added the board configuration block FROM THE MODEL LIBRARY -- so all default parameters. My model failed during the build, because of problems with the path initially, but then with a consistent error in build that no valid CPU was defined, and interrupt.h could not be found. Deploy failed, of course, with an error that there was no exec.

I put the configuration manager parameters boxes next to each other, between NXP's example and mine, and modified any parameter necessary to match the example exactly. The Target Configuration in the Block Parameters is set for OpenSDA, and the drive letter and label for the board are correct. All other parameters on all four tabs also match the example model. Still my model would not run, with the same set of errors as above.

More out of desperation than logic, I changed "mbd_s32k.tlc" in the Model Configuration Code Generation to "mbd_s32k14.tlc", and I got a different set of errors (which was refreshing). The errors are shown in the second file attached. So I changed it back to "mbd_s32k.tlc" and now it works.

To confirm this behavior, I used the right-click menu item to change all parameters back, and it still works. If I copy the block out of the library, it doesn't work until I change to "mbd_s32k14.tlc" and back again, without changing any other parameters, then it works.

A bug perhaps? Any way to avoid this annoying step?

Thanks, Nancy 

[neffnan]

Hi Marius,

Thank you for your reply. I completely understand the delay -- you all must be swamped on Monday mornings from those of us working over the weekend and furiously generating posts!

The problem with the mbd_s32k.tlc does seem to have gone away also. I will test it more today to confirm, and post that this problem is solved also if that turns out to be the case. However, the errors that occur when using the mbd_s32k14.tlc file persist. I wonder if it makes sense to have a file in the system that appears to be the correct one for the s32k14x MCUs but doesn't work?

Yes, I agree with you about spaces in file and directory names, but that directory is one generated by MATLAB during installation of the add-ons. I'm not wild about uninstalling and reinstalling everything because I don't remember being given the option to modify that path during installation, only the top-level location of MATLAB. Perhaps NXP could coordinate with MathWorks to have them generate only file and directory names that don't contain spaces? I myself never use spaces in file or directory names -- only CamelCase, dashes, or underscores. (I even avoid periods.)

Thanks again for the reply.

Best regards,

Nancy

[mariuslucianand]

Hello @neffnan ,

Sorry for my delayed answer. I've seen that you have also posted on a similar topic here https://community.nxp.com/t5/NXP-Model-Based-Design-Tools/MBDT-S32K-makefile-error-in-example-progra... 

Is this issue solved as well after reinstalling the Toolbox?

Also, from your screenshots, I've noticed the Toolbox is installed in a path that contains a space. During the time we have noticed some cases when spaces from inside the path create some errors so we encourage as a good practice to install MATLAB's Add-Ons in paths with no spaces.

Hope this helps,

Marius