Good day! I am currently working on an LLC resonant converter to be implemented using PLECS. In the lab, we currently have an RT Box, a TI F28069 LaunchPad, and a LaunchPad-Nucleo Interface board. I am planning to do a hardware-in-the-loop test with the aforementioned equipment and I came across this document which provides a demo model for LLC resonant converter implemented in TI C2000. However, the TI F28069 is not included in the list of controllers for this demo model as seen here.
With this in mind, I would like to ask where can I begin to configure the existing demo model to support the TI F28069 LaunchPad that we have? I am checking the initialization commands as a start but they can be a bit confusing. Any assistance would be greatly appreciated!
Hi imdaonlyjuan,
You can achieve this by referring to the RT Box LaunchPad–Nucleo Interface User Manual.
Specifically, see the LAUNCHXL-F28069M Pin Map section to understand how the RT Box pinouts map to the F28069 pins. Once you have that, you can modify the demo model to add F28069 support in the initialization script. You’ll need to:
-
Add target support and define a board type for the F28069 (lines 8–35).
-
Using the board type you defined above, add a case statement to configure the processor I/O (around line 113).
Hope this helps!
1 Like
Thank you for this, Ahmed! I was able to configure the PLECS model to accommodate the TI F28069 LaunchPad. Here is the file for your reference. I was able to run the model offline.
llc_resonant_converter_F28069M.plecs (230.8 KB)
That being said, I am now trying to connect to the TI F28069 LaunchPad via the External Mode where I now experience this problem as shown here in the attached picture.
My initial assessment is the 90MHz system clock of the TI F28069 LaunchPad but I would appreciate any clarification on the matter. Thank you very much!
Edit: Is connecting to external mode necessary for HIL testing in the first place?
Hi, unfortunately the F28069 is not as powerful as the rest of the controllers in the c2000 family as it is quite dated at this point. The control strategy in place in this model appears to cause interrupt/task overruns (i.e. it takes longer for the controller to execute the algorithm than is available between ISR calls).
This is not necessary but it gives you access to a soft scope that allows you to see what is happening internally in your controller - so it quite a useful feature as you work through the design process. Even without external mode you might still run into task overrun issues.
You have two options:
- upgrade to one of the later chips in the C2000 family. These run at much higher clock rate (e.g. the 28P65 runs at 200MHz) and thus is able to run high frequency controls like the one used in this model.
- reduce the controller task rate so that the 28069 has more time to execute the control algorithm. NOTE you will need to redesign the controller if you reduce the task rate.
Hope this helps!
I see I see. Thank you so much for the clarification! Perhaps my last question would be say I am limited with the 90MHz clock of TI F28069 LaunchPad, what parameters can I vary and where can I begin? Also will the discrete size step of 10usec in the RT Box CE be a limiting factor as well?
Hi imdaonlyjuan, I took a closer look at your model and noticed the following:
The model, as currently configured, is attempting to execute the control algorithm at 110 kHz. Unfortunately, this is well beyond the practical capabilities of the F28069.
I experimented with reducing the control algorithm rate and observed the following:
-
Reduced by a factor of 4 (ISR at 27.5 kHz):
At this rate, I was able to run the controller and connect via external mode. However, the CPU load is around 67 percent when the control algorithm is enabled. This is somewhat high, but it can be considered an upper limit. The model includes some well-implemented soft-start logic, and you may be able to reduce CPU usage by simplifying this logic or moving it to a slower task.
-
Reduced by a factor of 5 (ISR at 22 kHz):
At this rate, the CPU load drops to approximately 53 percent, which provides a comfortable margin in my opinion.
Note: Since the ISR rate has been reduced, the controller will need to be redesigned. The phase delay introduced by sampling will now occur at a much lower frequency than in the original design, and as a result, achieving very high loop bandwidth will likely not be possible.
Also will the discrete size step of 10usec in the RT Box CE be a limiting factor as well?
Just to clarify, the model you provided is configured for RT Box 1 with a plant discretization step of 2 µs.
The main workhorse of this HIL setup is the Nanostep solver, which runs at 7.5 ns on both the RT Box 1 and CE. The image below shows an example of the effective system configuration. While the example illustrates a DAB using the Nanostep solver on RT Box 2, the same concept applies to other Nanostep-based modules.
Given that your control algorithm needs to be reduced to approximately 20 to 25 kHz, a plant discretization step size in the range of 2 to 10 µs on the RT Box CE should not be a limiting factor.
Hope this helps!
