MATLAB Answers

Simulink for Texas Instruments C2000 microcontrollers: problem with distorted waveforms in the F28379D

201 views (last 30 days)
Gabriel Pauka
Gabriel Pauka on 29 Dec 2020
Edited: Gabriel Pauka on 2 Jan 2021
Dear all,
I am working with the LAUNCHXL-F28379D launchpad, from the series C2000 from Texas Instruments, using Simulink Embedded Coder Support Package for Texas Instruments C2000 Processors to code it. I am developing a control algorithm in my thesis and want to use said launchpad to implement it to control a permanent magnet synchronous machine.
I am using the BOOSTXL-3PhGaNInv with a three-phase Y-connected RL load to simulate a machine (up to a certain point) and test the functionalities in a safe manner. I am logging the signals using SCI communication and Simulink, to visualize all variables and signals. CPU1 sends the signals to CPU2 via IPC, which sends them to my PC via SCI. This was based on Antonin's DC/DC Buck Converter communication (available at https://www.mathworks.com/matlabcentral/fileexchange/61420-dc-dc-buck-converter-example?s_tid=prof_contriblnk). I had some problems so far, however I was able to solve all of them by searching in Texas Instruments' e2e forum and Mathworks' MATLAB answers... except for one, in which I have spent a couple of days without success.
To understand all functionalities and debug them properly, I am implementing my code by levels (as also done by Texas Instruments in Performance Analysis of Fast Current Loop (FCL) in Servo Drives Using SFRA on C2000™ Platform, available at https://www.ti.com/lit/an/sprt735/sprt735.pdf). I am now generating three-phase PWM signals in open loop, with a magnitude reference and angle being both generated internally. Here is a piece of my code that illustrates my goal:
To avoid bad signals being used to generate the references, the signal "ui" (user input) is generated by a hysterisis comparator, so it will either be zero or some fixed value, without noise and bad connections. The "Artificial Position Generator" genererates a clean sawtooth with a 100Hz frequency. The signals being fed into the ePWM modules are proved to be clean, as the modulation for ePWM1 (Ta) can be seen below. Please note that the switching frequency is 40kHz, so the signal to the ePWMs would be 200MHz/40kHz/2 = 2500 CPU counts maximum.
Therefore, we can eliminate signal integrity and control system issues, since the signals are generated internally and there is no control loop. Phases B and C were also validated, and have a clean waveform, just like Ta, but displaced 120º, as expected.
Regarding task scheduling: I saw Antonin's video, available at https://www.mathworks.com/matlabcentral/fileexchange/49109-dual-motor-control-with-ti-launchxl-f28069m-launchpad, that discusses how to schedule the ePWMs, ADCs and control loop. More information is also available at https://www.mathworks.com/help/mcb/ug/prepare-task-scheduling.html.
I understand and agree with the content: ePWM1 dictates the pace. When it reaches its counting peak (in the up-down mode), it sends an interruption to the ADCs to start their conversion. When they end, they generate an interruption that starts the algorithm. I am using three ADC modules, and module A has three channels. ia, ib and ic are sample together and first, since they are from independent modules and triggered by ePWM1A, and for purposes of control they need to be sampled together (even though ic is redundant, it is sampled anyway). After that, ui and VDC are sampled in order, since they have lower priorities in the ADC A module. When VDC (ADC A14) finishes, it generates an End of Convertion (EOC) interrupt, that it is called by a hardware interruption block and sends the signal to the whole code from the first picture, that it is located inside a triggered subsystem:
"System Initialize" only activated the pull-up resistor for the two digital inputs, and have no relevance here.
However, when I connect my LAUNCHXL-F28379D with the BOOSTXL-3PhGaNInv to an RL load, I obtain the following current waveforms:
In a switched converter, ripple is natural. But this... well... this is ugly. The waveforms remember sinusoidal ones, but they wave this bad distortion. What most intrigues me is that said distortion is "well-behaved". I ran (and logged) the test for 120 seconds, and a very similar current is obtained throughout the whole duration: same peaks and ripples ocurring in the same waves in the same positions. This was obtained with an amplitude at 95%.
Some extra information that might be helpul:
  • When performed said scheduling, I noticed that the whole system slowed down: both the LED blinking indicator and the PWM waveforms were half at their frequency. I noticed the option "EPWM clock divider (EPWMCLKDIV)" at the "ePWM" tab in "Taget hardware resources", and it was set to "SYSCLKOUT/2" (default). I changed it to "SYSCLKOUT/1", which solved that issue.
  • The dead time implemented in the PWMs are of 25ns, with an Active High Complimentary (AHC) polarity. I tried changing the dead time value, and no significant change was seen. I also changed the polarity to Active Low Complimentary (ALC), which caused the converter to drain 400mA at zero reference (i.e. all switching pulses were the same at 50%... or should be), which prompted me to abort the test. In the AHC polarity, no current is drained for zero reference. I also changed the Signal Source for both Rising and Falling edges to ePWMxB, which caused my DC power supply to enter in current limited mode at 2A with a zero reference. I will not repeat said mistake.
  • In some "stab in the dark attempts", changing the ePWM clock divider, the trigger for the system from ADCA to ePWM1A and the way that the ePWM trigger was generated (if the clock divider was at /2, I had to generate ePWM triggers at both period count and zero to compensate for it), the best looking waveform was obtained by setting the ePWM clock divided at /2, and the trigger for the system to its interruption, when the ePWM reaches both the period count and zero. This forces the control algorithm to be processed at the end of the PWM, instead of the end of the ADC conversions, contradicting the main idea behind this task scheduling... however, this was the result, for the same conditions from the first picture (95% modulation index, switching frequency of 40kHz and fundamental of 100Hz), however with the "wrong task scheduling":
  • Oddly, lower switching frequency resulted in a better quality waveform. This is the same fundamental frequency (100Hz) and modulation index (95%), for 10kHz of switching frequency, with the "correct task scheduling".
  • [SOLVED]Lower switching frequencies increase the current drained from the DC power for the same modulation index. For 95% modulation index, at 40kHz, the circuit drains 1.65A. For 20kHz, around 2A. And at 10kHz, 2.25A. Unfortunately, I cannot understand such change. [SOLVED] This one is my fault. The block responsible for generating the sawtooth as angle reference did not have any parameter that changed with the switching frequency, therefore 4x lower switching frequency resulted in 4x lower fundamental frequency, which feeding an RL load resulted in increased current.
  • Modulation indices at 100% causes the distortions to be "less periodic and well-behaved", but are still present and similar looking between fundamental periods.
  • I also checked the model "c28379Dpmsmfocdual_cpu1_ert", and verified its configurations. The task scheduling, ePWM clock divider and overall functionalities are the same as my model.
  • Since I bought two BOOSTXL-3PhGaNInv boards, I tried to switch to the one that I have never used. Same results.
So, I am really confused here. The task scheduling and switching frequencies changes the distortions in the opposed way: wrong task scheduling and lower switching frequencies improve the waveform quality. The switching frequency also changes the DC current drained. These distortions are not half-wave symmetrical, even though their PWM values are, discarding any load-related issues. They have a pattern throughout the whole test, indicating that the issue is "periodic" and have a well-defined source. The "control algorithm" is very simple, to the point of being fail-proof, and the PWM reference is crystal clear. All of this makes me think that I am messing up with something in the programming. Some parameter hidden in some block, that I was not able to see in none of those sources that I presented. Clearly this behaviour is not natural nor good, and I cannot proceed to my next level (closed current control loop) with this unsolved.
If someone can shine some light here, I would really appreciate. I tried to debug this for a couple of days, and researched a lot, but could not find anything. If I can provide any other detail, waveform or even files that can help, just let me know.
Best regards, (and happy holidays!)
Gabriel

Answers (1)

Gabriel Pauka
Gabriel Pauka on 2 Jan 2021
Update: after spending several hours rebuilding my model, changing settings back and forth, I "got stuck" with the following waveform, with an amplitude modulation of 100%:
Due to the COVID-19 measures, I am unable to go to my university and use their oscilloscopes and current probes for a couple of weeks, but I got myself a board with three LEM LA-55P current sensors, from a laboratory coleague. I also have an old and cheap PC oscilloscope, very limited, but better than nothing. Using the current sensors and the PC oscilloscope, that's what I obtained:
2ms/div was the highest time value that kept the sampling rate at 625kHz. With 5ms/div, it dropped to 39kHz, below the switching frequency, and would not be able to show too much details. The waveforms shown in both figures were created under the same parameters, but not during the same time, since there is nothing that synchronizes the PC oscilloscope and the data logging.
The blue phase of my oscilloscope is the same as the blue phase of MATLAB (Phase A), and the yellow phase of my oscilloscope is the same as the yellow phase of MATLAB (Phase C, the "ugliest" one). My PC oscilloscope only have 2 channels. With the current sensors and a PC oscilloscope, the waveforms seems... fine. A little noise here or there but it isn't even close to be as bad as the data obtained by the BOOSTXL-3PhGaNInv current sensors.
Unfortunately, I do not have enough components to make a signal conditioner to feed the LAUNCHXL-F28379D with the signals generated by the LA-55P transducers, that should be scaled down and offseted (to be within the 0~3.3V range), so I cannot acquire the "healthy-looking" signals with the microcontroller
Therefore, I am beggining to suspect that there is nothing wrong with the current waveforms generated by the BOOSTXL-3PhGaNInv. Maybe it is only a matter of a bad sensing circuit? Are the INA-240 current sensing op-amps that sensible to common-mode voltage over the 5mOhm resistors in series with the VSC outputs?
What still makes me question that is the fact that Phase C (yellow one) seems is the worst one for both BOOSTXL-3PhGaNInv boards that I own.

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!