@Anaïs, after thoroughly researching the MathWorks C2000 documentation including "Detect and Fix Task Overruns on Texas Instruments C2000 Hardware" ( https://www.mathworks.com/help/ti-c2000/ug/detect-and-fix-task-overruns-on-c2000-hardware.html ), "Scheduling and Timing" ( https://www.mathworks.com/help/ti-c2000/ug/scheduling-and-timing.html ), "Submodules of ePWM Type 1-4" ( https://www.mathworks.com/help/ti-c2000/ug/sub-modules-of-epwm-type-1-4.html ), "GPIO Digital Output" block reference ( https://www.mathworks.com/help/ti-c2000/ref/gpiodigitaloutput.html ), and "C28x-ePWM Configuration" ( https://www.mathworks.com/help/ti-c2000/ref/sect-hw-imp-pane-c28x-epwm.html ), I can definitively explain your issue and address your question about mapping PWM signals to ePWM modules. You're experiencing a task overrun where, as the MathWorks overrun documentation states, "A task overrun occurs if the target hardware is still performing one instance of a task when the next instance of that task is scheduled to begin," and your model is taking about 1,250 microseconds to execute but is configured to run every 50 microseconds, causing the scheduler to skip 24 cycles and only execute every 25th interrupt, which explains your exact 25x slowdown with both GPIO and ePWM outputs. The scheduling documentation explains that "each iteration of the model solver is run after an interrupt has been posted and serviced by an interrupt service routine" using CPU_timer0, and when your code exceeds the time budget, the system cannot keep up regardless of whether you use GPIO or ePWM outputs. To confirm this, enable overrun detection as documented where " you can configure a Simulink model running on the target hardware to detect and notify you when a task overrun occurs" by going to Configuration Parameters, Hardware Implementation, Target Hardware Resources, Overrun detection, enabling it with GPIO31 set to toggle mode, and if it toggles continuously on your oscilloscope you have confirmed constant overruns. Your fundamental architectural problem is that your SVM is outputting binary switching patterns to GPIO blocks, which the documentation describes as blocks that " configure general-purpose I/O pins as digital output" where " a value of True at the input drives the GPIO pin high" requiring software execution for each transition, but you should instead restructure your SVM to output duty cycle percentages for each of the nine switches and feed these into properly configured ePWM hardware blocks. Regarding your specific question about how to correctly map PWM signals to ePWM modules, the F28379D has fixed GPIO pin assignments for each ePWM module that cannot be changed, as explained in the MathWorks forum where it states " the GPIO pin mapping to each PWM pin is fixed for TI Delfino" processors, and according to the LaunchPad documentation the default ePWM to GPIO mappings are ePWM1A on GPIO0, ePWM1B on GPIO1, ePWM2A on GPIO2, ePWM2B on GPIO3, ePWM3A on GPIO4, ePWM3B on GPIO5, ePWM4A on GPIO6, ePWM4B on GPIO7, ePWM5A on GPIO8, ePWM5B on GPIO9, ePWM6A on GPIO10, ePWM6B on GPIO11, ePWM7A on GPIO12, ePWM7B on GPIO13, ePWM8A on GPIO14, ePWM8B on GPIO15, and ePWM9A on GPIO16, ePWM9B on GPIO17, which you can verify by navigating to Configuration Parameters, Hardware Implementation, Target Hardware Resources, ePWM where the documentation states you can " visualize the pin assignment" for your processor. The ePWM documentation explains that " several motor control and power electronics applications use the enhanced Pulse Width Modulator peripheral" with hardware submodules including "Time-Base" that "enables configuring the period and mode at which ePWM counter operates," "Counter Compare" that "compares the time-base counter value with the counter compare registers," and "Action Qualifier" that "specifies the action to be taken on the ePWM output when time-base and counter compare events occur," meaning the hardware generates switching at nanosecond precision while your CPU only updates duty cycle values at 20 kHz. Configure each ePWM block with timer period calculated as "Base rate sample time = Timer Period × Prescaler / CPU Clock Speed" set for your switching frequency in up-down counting mode where "the time-base counter value starts from zero and increases until TBPRD is reached, once the counter reaches TBPRD the counter decreases until it reaches zero," with counter compare units set to percentages receiving duty cycle inputs, action qualifiers configured so when counter equals CMPA on up-count it clears and on down-count it sets to create symmetric PWM, synchronization where ePWM1 is master generating sync-out when counter equals zero and ePWM2-9 are slaves receiving this sync signal which is critical for your matrix converter to prevent creating short circuits between input phases, and dead-band delays configured in each ePWM block to prevent shoot-through. As the overrun documentation recommends for fixing overruns, " reduce the processing burden of the model by increasing the sample times, simplifying the model, or using profiling to measure execution time of each task," so as a quick diagnostic test temporarily change your fixed-step size to 1.25e-3 seconds, and if your outputs now match that 800 Hz rate you have confirmed the model executes correctly at slower speeds and needs optimization through lookup tables replacing trigonometric functions, fixed-point arithmetic where possible, pre-calculating constants, and using the profiler to identify bottlenecks before restructuring to the proper ePWM duty-cycle based architecture that power electronics applications require.
Let me know how it goes.
