CHB Inverter PWM Synchronization Issues with Two F28379D DSPs

[MHz]

I am currently developing a Cascaded H-Bridge (CHB) inverter model and would like to evaluate the multi-channel PWM generation and synchronization capabilities using the two TI F28379D DSP boards.

I have attached two PLECS models, CHB_PWM_option1 and CHB_PWM_option2, which demonstrate the issues I am currently facing.

CHB_PWM_OPTION1.plecs (304.0 KB)

CHB_PWM_OPTION2.plecs (293.8 KB)

1. CHB_PWM_option1 – PWM synchronization using the standard PWM blocks

For Phase A and B, I am able to synchronize the PWM signals for the two cascaded modules correctly, and the resulting CHB output waveform is as expected when i ran simulation.

However, when I use two DSP boards to independently generate the PWM signals for Phase A and Phase B, I am unable to maintain the required 120° phase shift between the two phases. The relative phase between Phase A and Phase B keeps drifting when I was running the real-time of HIL+DSP operation modes.

I was using the C2000 PWM blocksets and try to configure the synchronization input to External. However, after selecting External synchronization, the Synchronization Output option which is not available. After reading the related thread and found which can be alternatively use the PWM variable blocksets.

2. CHB_PWM_option2 – PWM synchronization using PWM Variable blocks

I found the following discussion on the PLECS User Forum regarding synchronization between two LAUNCHXL-F28069M boards Two LAUNCHXL-F28069M Synchronize issue - Coder / TI C2000 - PLECS User Forum. I tried to follow the same procedure to form a two DSP board PWM synchronization method.

For the CHB_PWM_option2 PLECS model,:

Based on that forum discussion, I attempted to implement a similar synchronization method using the PWM Variable blocks and an External Sync signal for the two DSP boards.

However, after applying the same PWM phase settings, the resulting Phase A waveform is different from the waveform obtained with CHB_PWM_option1. Therefore, I am not sure whether my PWM Variable configuration, synchronization source, or phase-shift settings are correct.

Thanks, i am looking forward to hearing from the technical support.

Regards,

MHz

[Bryan_Lieblick]

Thanks for the detailed description and model files.

1. CHB_PWM_option1 – PWM synchronization using the standard PWM blocks
…
The relative phase between Phase A and Phase B keeps drifting when I was running the real-time of HIL+DSP operation modes.

This is to be expected. They are two separate DSPs with two different clocks that will naturally drift from each other.

I’ll also point out that you’ll likely encounter another synchronization related issue (if you haven’t already noted this). The sine generators for the duty cycle inputs are independently generated on each MCU. These also will drift over time and either need to come from a common source or be synchronized in some way.

After reading the related thread and found which can be alternatively use the PWM variable blocksets.

Yes, the more advanced PWM block is a workaround for your case.

For future users, I’ll also point out that the unique grouping here of 3 PWM generators sync’d is due to the specifics of the 28379D target, as explained in this forum post. You could group all PWMs into a common block for other targets.

2. CHB_PWM_option2 – PWM synchronization using PWM Variable blocks
However, after applying the same PWM phase settings, the resulting Phase A waveform is different from the waveform obtained with CHB_PWM_option1.

In your offline simulation you swapped the two PWM ports. “PWM (Variable)1” and “PWM (Variable)” are fed into the incorrect multiplexer inputs. Perhaps more descriptive names would help. Switching those fixed the issue in the offline simulation.

In the HIL implementation you are using a RT Box digital outputs (DO-8 and DO-9) that don’t map to a GPIO on the 28379D. You might be using fly wires since you’re connecting two boards to synchronization signals coming from 1x RT Box. For phase A I changed the pin assignment to DO-2 and GPIO 67 and it worked fine and matched the original implementation.

I also noted that you can have a more efficient real-time implementation by using the “Number of cells” setting with the “Full Bridges (Series Connected)” component rather than having two separate full-bridges.

Also, the effective output frequency is 40 kHz which is high relative to the CPU time step you chose at 5 usec (Tpwm/Ts_rtbox= 5). This results in a notable distortion near the current zero crossing. In my testing the step size can be decreased to 2 usec on the CPU (Tpwm/Ts_rtbox= 12.5) or even better set the system to use the FlexArray for a 154 nsec step size (Tpwm/Ts_rtbox= 162).

You can see the changes in the attached model. Note I didn’t make any modifications to the B_phase subsystems. CHB_PWM_OPTION2_BL.plecs (283.1 KB)

[MHz]

Hi Bryan,

Thanks for your quick response and for helping me resolve the model issue. Sorry for the late reply. I have been working on the HIL implementation and encountered several issues when connecting two DSP controllers simultaneously.

For the offline simulation using CHB_PWM_option2, I am now able to obtain the expected results after following your suggested configuration.

However, I am still having difficulty connecting both DSPs at the same time. The issue occurs mainly with my option_ctrl_2_A_phase setup. Based on your previous suggestion, I understand that the CHB_Plant model should use a 2 µs timestep to avoid current distortion.

For the Phase-A RT-BOX and LaunchPad interface, DO-2 is internally routed to GPIO67. For the second DSP controller, I still need to synchronize the DSPs. Therefore, I am currently considering the following two configurations:

• Jumper connection type 1: Use DO-2 → GPIO67 for the first DSP and DO-9 → GPIO67 for the second DSP.
• Jumper connection type 2: where DO-8 and DO-9 physically jump are connected to GPIO67 of the Phase-A and Phase-B DSP controllers, respectively.
  
  
  

The photo above shows my current setup using two RT-BOX 2 units and two F28379D LaunchPads.

Connection Issue with Two F28379D Controllers

For debugging, I first connect both F28379D LaunchPads to my laptop through two USB connections. I can successfully build and connect to both DSPs before powering on the RT-BOX 2 units.

However, after I build and connect both Phase A and Phase B models to the RT-BOX 2 units and power up the system, I frequently failed the connection to the Phase-A F28379D. However. only Phase-B F28379, RT-BOX2 of Phase A&B is connected successfully so i only can get Phase B results.

So here is the phase B output results

Even i tried to unplug and reconnect the USB cable, power-cycle the RT-BOX/DSP setup and
reconnect everything again.I still cannot reconnect to the Phase-A F28379D after several attempts.

I have three RT-BOX 2 units available, and the problem seems to occur mainly with Phase A. Therefore, I am not sure whether the issue is related to the DSP controller, RT-BOX 2, synchronization connection, or model execution.

I noticed from your previous model settings that you were using RT-BOX 3 and RT-BOX 4. In my setup, I am using RT-BOX 2 to generate two 10 kHz PWM groups. Could the RT-BOX 2 configuration or computational load cause overrun/timing issues that could affect the DSP connection?

I am looking forward to hearing from your suggestion.

Regards,

MHz

[Bryan_Lieblick]

I understand that the CHB_Plant model should use a 2 µs timestep to avoid current distortion.

Yes, or FlexArray!

Therefore, I am currently considering the following two configurations:

I think it’s immaterial which connection approach you choose.

I will recommend a third approach which is to synchronize the two RT Boxes over their SFP connection. Then have the RT Box generate a pulse that is routed through the interface board instead of having the jumper connections. You can account for the inter-RT Box communication delays (2x CPU time steps) by adding a corresponding delay in the model of the sending unit.

In the Coder options + Target + Interconnect select:

Subsystem	Primary box for startup/clock	Synchronize Startup with SFP A	Use clock from primary box
A_PHASE_CHB	Self	✓
B_PHASE_CHB	SFP A	✓	✓

I tested:

• DO 8 and DO 9 connecting to GPIO 61 as the sync pin:
  • Assume no skew for sync pulse
  • PWM signal skew is -30/+20 nsec
• Use SFP to synchronize and generate pulse locally (no jumpers)
  • Sync pulse skew is +/-30 nsec
  • PWM Signal skew is -60/+40 nsec (basically cumulative)
• In these tests I set the sine generators frequency and phase to 0 so the duty cycle inputs were constant to make comparisons easier.

I frequently failed the connection…

This was the major issue that interfered with my testing.

This is due to the timing scheme in your model. You don’t have an explicit trigger that causes the model to run, but the Coder automatically selects the trigger as the PWM carrier of the primary channel. However, it seems that there can be an issue when the External Synchronization input is used, especially when Fsync ~= Fpwm. I suspect the next sync input can come just after the last model trigger, which retriggers the model and causes an overflow. If you use the Timer block to trigger the model execution the problem goes away. The “A” phase subsystem seemed more sensitive to this.

Could the RT-BOX 2 configuration or computational load cause overrun/timing issues that could affect the DSP connection?

The RT Box configuration should generally not impact the timing of the MCU, with the exception of the RT Box outputs influence the behavior of the MCU. For example, the sync pulse from the RT Box in your model. In other models it could be that a certain code-branch is executed due to the state induced by the RT Box outputs. However, with respect to this timing behavior the RT Box 2, 3, and 4 will be equivalent.

You can refer to this model to see the changes made:
CHB_PWM_OPTION2_SFP_BL.plecs (197.8 KB)

[MHz]

Hi Bryan,

Thank you for sharing the third approach and for your professional guidance in helping me resolve the issues.

I am now able to run both DSP controllers simultaneously while connected to two RTBOX-2 units. However, I noticed that Phase A and Phase B are still drifting relative to each other during operation.

Could you please review the GIF I uploaded below and advise on the possible cause of this phase drift? I tried both solution either SFP+ internal DO2&GPIO69 or the jumper wires DO 8 and DO 9 connecting to GPIO 61. Both getting the same results.

Any recommendations for further synchronization checks or configuration adjustments would be greatly appreciated.

Thank you for your support, Looking for your next reply

Best regards,
MHz

[Bryan_Lieblick]

Hi MHz,

I alluded to this in my first response:

@Bryan_Lieblick

I’ll also point out that you’ll likely encounter another synchronization related issue (if you haven’t already noted this). The sine generators for the duty cycle inputs are independently generated on each MCU. These also will drift over time and either need to come from a common source or be synchronized in some way.

Since the two MCUs have independent clocks they will naturally drift over time unless explicitly synchronized.

The best way to handle this is more of an architecture decision on how you want to structure your system with regards to where the “main” controller is, how it communicates to peripheral devices, etc. Two approaches:

• You can re-use the SFP-based inter-RT Box communication approach and have the RT Box send the sinewave out over the local Analog Out channels to the MCU DSP.
• In theory if the PWM’s are synchronized and the PWMs trigger the control task, then the control tasks will also be in lock-step. However with the “default” configuration in your previous model this caused overruns. The simplest approach for the purposes testing was to have the timer generate the control task interrupt (ISR). You could experiment with other approaches to make the MCU less sensitive to this issue. A few that come to mind, but I have not evaluated:
  • Trigger the control task on the Overflow rather than Underflow / zero count (set in the PWM block under Events + Task Trigger)
  • Add small phase shift to primary channel to prevent double triggering the control task.
  • Set the sync pulse to be Fsync < Fpwm to prevent retriggering within the same PWM interval.
  • Some C2000 devices have the Fast Serial Interface (FSI) which can be used to synchronize multiple controllers. This currently isn’t supported by the Target Support Package offered by Plexim, but it’s worth highlighting as this is an intended application of the feature.

[MHz]

Hi Bryan,

Thanks for your suggestions. I tried your approach by generating two sine waves from the first RT-BOX 2 plant model from RTBOX AO and feed to DSP AI port. Hence the sine-wave clocks can be synchronized, and it work fines. The Phase A&B no more drifted while running the inverter operation.

However, I noticed that the DSP connection may fail sometimes, but adding the timer does help.

Above results, the current distortion is relatively high, which I believe is due to the slow step size execution for the DSP controller so the ADC sample resolution is low. If I reduce the DSP execution/discretization step size from 100 µs to 50 µs, I assume I will also need to adjust the corresponding timer frequency from 10kHz to above frequency? Please let me know if my understanding is incorrect.

When I changed the DSP discretization step size from 100 µs to 50 µs but my timer blocksets in DSP still under 10kHz, I encountered the error shown below.

By the way, I think using two sine-wave references is the simplest approach, but it may be more suitable for open-loop testing only.

My next step aims to design the closed-loop control for the CHB inverter. I also tried the HIL + DSP for 3-phase CHB model for a single module in each phase. However, I was using only one RT-BOX and one DSP to utilize the 6 EPWMs in a single DSP. I will need your advice if i want to implement 3-phase CHB for more modules, what’s better approach to structure based on HIL+DSP setup?

In addition, if I further expand the system for closed-loop control scenarios that no rely on the sine-wave generators, would I need to use the Fast Serial Interface (FSI) for synchronization and communication? or any approaches. Looking forward your next reply

Regards,
MHz

[Bryan_Lieblick]

@MHz

If I reduce the DSP execution/discretization step size from 100 µs to 50 µs, I assume I will also need to adjust the corresponding timer frequency from 10kHz to above frequency?

That’s correct, with your model configuration if the discretization step size and the CPU timer frequency disagree then you will receive an error. You can create an initialization variable to set both so they are always in sync. If you get frequent overruns you can review this article for additional suggestions.

@MHz

I will need your advice if i want to implement 3-phase CHB for more modules, what’s better approach to structure based on HIL+DSP setup?
…
In addition, if I further expand the system for closed-loop control scenarios that no rely on the sine-wave generators, would I need to use the Fast Serial Interface (FSI) for synchronization and communication?

These are really design controller architecture questions for you to work through on your side. Your multiple controllers need common grid-level and modulation-level inputs and have to be synchronized in some way, whether that’s through the PWM sync, communication buses like SPI and CAN, FSI, or some combination thereof. Setting up FSI along with synchronized PWMs is quite complex to code and is also not supported by the TI C2000 TSP from PLECS.

[MHz]

Hi Bryan,

Thanks for your suggestions and help on this post. I’ll explore the possible solutions further. Most likely, this kind of work will require some handwritten code to configure the more complex drivers, as you mentioned. I’ll continue looking into it and may post more questions here in the future. Thanks again for your help!