When I try uploading my model of a FOC controller to a Launchpad XL28379D ver: 2.0 it works like it should, following my speed reference correctly, but at the moment of entering Coder > Coder options… > External Mode and selecting the corresponding serial port the following error shows:
I configured the Launchpad in the Target tab like the following:
In the Target > External Mode tab, the GPIOs selected are 43 and 42.
I don’t know if the issue is my model, the Launchpad, the C-Script block, the amount of Scope blocks or some other problem.
Things that I already tried:- Changing the Launchpad jumpers.- Activating/deactivating the Load VCP option in both XDS100 Class Auxiliary/Debug port.- Trying a different COM port.- Using the built-in example TI C2000 Target Support Demos > Basic Topologies > Simple Model. The external mode works flawlessly with this example.
Photos of my model:
Eduardo,
When you connect to the External Mode do the LEDs on your LaunchPad device stop blinking or continue to blink?
Initiating the External Mode connection will increase the CPU load. It is possible that when you connect the CPU load exceeds 100% and the processor halts. The LEDs ceasing to blink is an indicator the processor has halted. At such a point the External Mode will not work.
Regards,
Bryan
Bryan,
Thank you for your response. Looking at the LEDs, they continue to blink, and the PMSM I’m controlling keeps rotating. Although, doing another test using the CPU Load block, the model compiles and it gets flashed correctly to the MCU, but the LEDs stop blinking.
Could the problem be related to the fact that I’m using the Launchpad XL28379D instead of the XL28379S, which is displayed in PLECS as an option?
Regards,
Eduardo
Eduardo,
The 2837xS target simply means that the TI C2000 TSP will program only one of the two available cores. The model should be compatible with your hardware.
The fact that the “Simple Demo” works fine and your PMSM model has an issue points away from a hardware/setup problem and toward something specific with your model.
Can you post your model here or send it to support@plexim.com for additional feedback? Thanks,
Bryan
Bryan,
I have send you an email with the requested files.
Thanks,
Eduardo.
Eduardo shared his model via support@plexim.com. The issue was due to the CPU load exceeding 100%.The key to improving Eduardo’s model and reducing the CPU load was to replace all double precision floating point calculations (double) with single precision calculations (float) with the model C-Scripts.The behavior of code generated from the PLECS schematic (excluding C-Scripts) is configured by the “Floating point format” setting in the Coder + Coder options… + General tab. The C2000 TSP enforces that this setting is “float” for computational efficiency. However, C-Scripts hold true to the data-type used in the script. It’s perfectly valid to use either “float” or “double” in the script and you should not get an error. A better solution though is to use the “real_t” datatype, which uses the global setting configured in the Coder Options. This corresponds to the “floating point (target default)” setting for the “Data Type” block. The conversion then is done automatically between floats and doubles.
So to summarize, when using C-Scripts with the TI C2000 TSP, the real_t datatype will generally be more efficient:
static real_t variable1; // preferred floating point format
static double variable2; // not preferred - higher CPU load for calculations
Exactly.Thanks to PLECS support we confirmed the CPU overhead and it was caused by the data type used in the C-Script code.
With Bryan’s explanation I was able to learn how to better optimize the C-script programming for an implementation.
Getting changes in the code declaration section of the C-Script block like the following image:
With this modification the external mode connection is successful. From the ETL lab of the University of Talca, Chile.Our regards.Thank you.
