Compiler/TMS320F28069: Simulink external target C2000 Code generation failure

Mark,

The first set of errors during linking are happening because there are libraries specified but they do not exist.  The first one is:

error: cannot find file "C:/Program Files/MATLAB/R2020b/toolbox/physmod/simscape/engine/sli/lib/win64/ssc_sli"

This actually looks more like a search path than a library.  In the linker options under File Search Path the top section is used to specify the library names to include and then the bottom section is for the locations to look for them.  It is possible to specify a path in the top section along with the library name.  

Is "ssc_sli" a file name?  i.e. if you go to "C:/Program Files/MATLAB/R2020b/toolbox/physmod/simscape/engine/sli/lib/win64" is that file there?  It is odd that there is no file extension.  I also find it odd that there is "win64" in the path.  Generally I try to avoid spaces in paths but that doesnt look like it is causing a problem here.

We do not have access to MatLab so we are not going to be able to do anything with the attached model.

Regards,

John

Hi John,

Thanks for following up.

Here's the contents of the directory at the location of the missing files. All the libraries are named ssc_sli_<something>.lib

It appears the linker lines are truncated. I reinstalled MATLAB to C:\MATLAB to remove spaces and shorten the path and confirmed the new path in the linker. The build errors were still the same.

Mark Edwards1 said:

All the libraries are named ssc_sli_<something>.lib

Extending Embedded and Generic Real-Time System Target Files suggests a Simscape model can generate code for an embedded target. I think you should ask MathWorks support about the linker errors, and how to generate a Simscape model to target a C2000 device.

Chester is right, none of those look like C2000 libraries.  Your best bet is to contact the Mathworks.  I found some references online that suggest this is possible if you have C2000 Embedded Coder but you will need to work with the Mathworks to figure it out.

Regards,

John  

Hi there,

I did have a discussion with Mathworks and they told me its a problem with the TI compiler (doubtful..).

So... can you help me with some specific questions to ask of Mathworks, and I'll try get them to do some work on this.

Thanks.

Chester Gillon said:

I don't have the required MATLAB toolbox licenses to check, but I think those libraries are all for Windows compilers.

All of the library files in the C:\Program Files\MATLAB\R2020b\toolbox\physmod\simscape\engine\sli\lib\win64 directory are for Intel (either 32 or 64 bits). objdump reports the following file formats:

• elf64-x86-64
• pe-i386
• pe-x86-64

Mark Edwards1 said:

So... can you help me with some specific questions to ask of Mathworks, and I'll try get them to do some work on this.

Ask them where to get simscape libraries that are built for TI C2000 devices.

Regards,

John

Will do, although Simscape blocks compile to generic fixed point C code which should be compatible with any embedded target.

There's no IO or target specific functions. Not sure what about Simscape would need be specific to C2000?

Hi Brian,

As no I/O or C2000 specific features are compiled by Simscape blocks I was of the same opinion as you, that Simscape compiles to C which is linked for embedded C target compilation just like any other Simulink block.

However, I have a support case open for this with Mathworks (Jonathan Chang [ ref:_00Di0Ha1u._5003q1MYrAG:ref ]) who stated:

"This error is the result of the Simscape PMLSM block not being supported for Embedded Coder generation. Unfortunately, it looks like the error message that results from this lack of compatibility is inaccurate."

Now, I've no idea why this Simscape block is supported by Simulink C coder but not by Embedded coder (or why it needs be) in this case.

With that said, the first two goes around with Mathworks support they were insistent the errors were due to TI compiler errors so I've little faith in what I'm being told, and still without a solution. If you can help, I would much appreciate your help. 

Cheers,

Mark.

Hi Mark,

I have heard of other products not having full compatibility for ECoder support; so this definitely seems plausible. Sorry about that. I'll guess and say it may have to do with code optimizations - regular generated C code is ok for testing and simulation, but not optimized for embedded applications (which is why you should use Embedded Coder). Nothing you can do to fix this, but typically these issues are passed from tech support to development as an enhancement for future releases.

I would suggest a "workaround" and use native Simulink blocks to build up your own PMSM switching logic to replace the Simscape block. Native Simulink blocks have ECoder support, and optimize well. You can probably whip up something quick to test and see if replacing the PMSM block will allow your model to build correctly. However, it may take some time to craft your PMSM logic so it works the way you want it to.

Note: We have a Motor Control Blockset product which does work completely with ECoder, and has PMSM block support, but I think the fidelity of the PMSM blocks is a notch more generic then the detailed first principle equations from Simscape. But maybe this would be sufficient / appropriate for your project.

https://www.mathworks.com/help/mcb/ref/surfacemountpmsm.html

Cheers,

-Brian

Thanks for your reply Brian,

I'm working on a linear motor and the PMLSM block parameterizes well to my actual plant. It's a single block that consumes 3PH currents, and outputs motion which is just what I need for an observer control scheme. 

Is there a way to compile just that block to C and include as external code or S-function as work around?

Will take a look at the motor control blockset you referenced, thanks.

Mark.

Hi Mark,

 You could try as you suggest, to generate regular C code with Simulink Coder, and then try and dig out the implementation, and import as legacy C code (C Code S-function).I have no idea if this workaround will end up with what you want, but certainly worth a try - and would be faster then trying to write your own C-code s-function block. I might do a quick build test without the PMLSM block first, just to verify there are no other gotchas in your model when you generate code.

One caveat which I suspect you already know: The sample time for stable simulation in Simscape Electrical may not match what you can actually achieve on an MCU. For controls that deploy to embedded systems, you typically see lower fidelity and slower sample times. Also the solver may change / be implemented differently. YMMV - but I've seen Simscape Electrical systems with lots of "stiff" switching which simulate wonderfully but end up being impossible to implement on an MCU.

Cheers,

-Brian