CCS/TMS320F28377S: ecap_capture_pwm_cpu01 Pins are not outputting PWM

Hi Derek,

You should expect ePWM3 to come out on GPIO4. This would occur after you connect the emulator, load the code, and then start running the code.

What HW are you using? Is this a TI kit/EVM, or custom HW?

You can verify that the GPIO mux is setup correct by looking at the GPIO mux registers in the expressions window. For GPIO19 you could look at GpioCtrlRegs.GPAMUX1.bit.GPIO4 and GpioCtrlRegs.GPAGMUX1.bit.GPIO4.

You could also run some of the other ePMW examples to see if you can get those to work.

I am using an official TI Hercules Launchpad, TMS320F28377S.

I have tested GPIO4. The pin drives high but does not oscillate like a PWM.

I would like to schedule a screen share, as that would be the best way to solve the issue.

I would like to request a screen share. How soon can someone connect with me?

Hi Derek,

Can you clarify which launchpad you have (taking a picture of it may be helpful).

Hercules is a line of Safety oriented MCUs that have ARM 'R' series cores. See here:
www.ti.com/.../launchpads.page

C2000 is a line of MCUs targeted towards real-time control. See here:
www.ti.com/.../launchpads.page

TMS320F28377S is definitely a C2000 part number and we do have a corresponding launchpad (marketing family is 'Delfino'), but we would need to get you help elsewhere for troubleshooting a Hercules Launchpad.

Here is a photo of the microchip, as well as the box it came in.

I'm running out of time. Can you please have someone connect with me via screen share and help me set up and get this PWM module working? Platforms I have access to are Skype, Google Hangouts and Team Viewer. If you have another I would be happy to set it up.

Hi Derek,

Ok, thanks for posting the kit info.  

We are limited to support via the e2e here, but we'll do what we can.

--------------------------------------------

You said that the pin drives high? Is this only after you load and run the code?  

------------------------------------------------

You can manually toggle a pin to verify hook-up by doing the following:

Launch a debug configuration, then 'connect', then 'load program' (or load symbols) from any project with bitfield defines

(.\ti\c2000\C2000Ware_1_00_02_00\device_support\f2837xs\examples\cpu1\ecap_capture_pwm\cpu01 project should be fine for this)

Then in the  expressions window, set

• GpioCtrlRegs.GPAMUX1.bit.GPIO4 to 0
• GpioCtrlRegs.GPAGMUX1.bit.GPIO4 to 0
• GpioCtrlRegs.GPADIR.bit.GPIO4 to 1

This configures GPIO4 as a general purpose output.  You should then be able to directly control the output state by changing

• GpioDataRegs.GPADAT.bit.GPIO4

In the expressions window (1 = high, 0 = low): 

--------------------------------------------------

Is the software you are trying to run coming from C2000ware, ControlSUITE, or somewhere else?  It is probably a good idea to download the latest version of C2000ware (C2000Ware_1_00_02_00) if you haven't already.

--------------------------------------------------

Have you run a more basic example like?

\ti\c2000\C2000Ware_1_00_02_00\device_support\f2837xs\examples\cpu1\blinky

This is a good one to check because the LED won't blink if your target configuration/project doesn't have "_LAUNCHXL_F28377S" defined (which can cause issues with other projects).

I am running "ecap_capture_pwm_cpu01", which has come from ControlSUITE. Here is a screenshot of my oscilloscope, which shows that GPIO4 is driven high and maintains a constant output of 3.3 Volts.

I tried running the "blinky" example, and the LED blinked as expected once I defined "_LAUNCHXL_F28377S" in the project settings.

I defined "_LAUNCHXL_F28377S" in the settings of "ecap_capture_pwm_cpu01" as well, but the pin that should be oscillating, EPWM3a on GPIO4, is still only driven high as shown in the screen shot.

The documents and suggestions you are sending me are not helping. I was told in an email from TI technical support that I could request a screen share by posting here on e2e, so I know that someone can do a screen share with me. The email I recieved follows below:

"Hello Derek,

I would then check the system clock. Check that the PLL is correctly locked and the device is operating at the desired SYSCLK frequency.

InitSysCrtl();  In this function there is a function which adjusts the PLLSYSCLK, which is the same as the SYSCLK.

InitSysPll(XTAL_OSC, IMULT_40, FMULT_1, PLLCLK_BY_2); // 10 MHz* 40 * 1 /2    -> then the SYSCLK runs with 200MHz

Check out the suggestions below :

https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/534845/1947860#1947860

Unfortunately I am not authorized to do any screen sharing. TI policy. To request that service please post this online at the e2e forums for C2000 chips : https://e2e.ti.com/support/microcontrollers/c2000/f/171  and if the personal agrees you can take the conversation offline and pursue it thereafter.

Regards,

 

Kishen Someshwar
TI Applications Support
Americas Customer Support Center
512-434-1560"

Please direct me to whoever it is that can provide me with this screen share service.

 

Hi Derek,

We also are not authorized for this.

I've verified experimentally that the following will cause GPIO4 to toggle due to the ePWM even when the CPU is not running:

EALLOW;
GpioCtrlRegs.GPAMUX1.bit.GPIO4 = 1; // Configure GPIO4 as EPWM3A
CpuSysRegs.PCLKCR2.bit.EPWM3 = 1; //ePWM clock enabled
CpuSysRegs.PCLKCR0.bit.TBCLKSYNC = 0; //ePWM clock gated
EPwm3Regs.TBCTL.bit.CTRMODE = 0; //ePWM up count
EPwm3Regs.TBPRD = 250; //ePWM period = 250 ePWM Clocks = 500 SYSCLKs
EPwm3Regs.AQCTLA.bit.PRD = 3; //toggle GPIO4 on ePWM period match
CpuSysRegs.PCLKCR0.bit.TBCLKSYNC = 1; //start ePWM clock
EPwm3Regs.TBCTL.bit.FREE_SOFT = 3; //ePWM free run

You can run this code or directly enter these register settings into the expressions window. Changing TBPRD will change the frequency.

They key difference between this and the example you are running is 'FREE_SOFT = 3'. This allows the ePWM time base to continue running even when the CPU is halted (which would happen if you pause the code, the code finishes, or the code hits a SW or HW breakpoint)

Also, as best I can tell from the documentation (I unfortunately don't have a F28377S Launchpad here) this should be the pin you want:

Thank you, the sample lines of code you have sent me are helping me make progress. I am now able to see the PWM oscillating. I am still stuck, I am unable to change the duty cycle.

Do you know which register to write to to set the duty cycle? My understanding is that it is CMPA, however when I insert the line "EPwm2Regs.CMPA.all", the PWM is not affected in any visual way. I have tried setting it to multiple values, but the duty cycle remains the same. Here is the code I am using:

EALLOW;
GpioCtrlRegs.GPAMUX1.bit.GPIO2 = 1; // Configure GPIO4 as EPWM3A
CpuSysRegs.PCLKCR2.bit.EPWM2 = 1; //ePWM clock enabled
CpuSysRegs.PCLKCR0.bit.TBCLKSYNC = 0; //ePWM clock gated
EPwm2Regs.TBCTL.bit.CTRMODE = 0; //ePWM up count
EPwm2Regs.TBPRD = 25; //ePWM period = 250 ePWM Clocks = 500 SYSCLKs
EPwm2Regs.AQCTLA.bit.PRD = 3; //toggle GPIO4 on ePWM period match
CpuSysRegs.PCLKCR0.bit.TBCLKSYNC = 1; //start ePWM clock
EPwm2Regs.TBCTL.bit.FREE_SOFT = 3; //ePWM free run
EPwm2Regs.CMPA.all = 6400;
EDIS;

Hi Derek,

The ePWM output can be toggled or driven high or driven low from a variety of events.  Currently, the only event causing an output state change is this:

EPwm2Regs.AQCTLA.bit.PRD = 3; //toggle GPIO4 on ePWM period match

Which does not depend on the setting of comare A or B.

If you look at the other fields in the AQCTLA register, you will see that you can cause a variety of state changes at a variety of different points in the timer cycle.  These include events based on compare A and B.

Note that because of 

EPwm2Regs.TBCTL.bit.CTRMODE = 0; //ePWM up count

The epwm timer is only counting up. You can get more flexibility by setting the timer to up-down count mode instead.

Also note that this register controls the A output of ePWM2 (currently GPIO4) but that there is also an AQCTLB register which can be used to control a second ePWM pin (GPIO5) from the same time base. Both A and B outputs can take actions off of period, zero, compare A, and compare B events, so using compare B to control GPIO4 duty cycle would be just as valid.  

Derek,

From the code snippet you sent, your TBPRD value < CMPA value. With this configuration your TBCTR will never reach CMPA as it get reset when TBCTR = TBPRD. This is the reason why you don't see any change in duty cycle.

Set your TBPRD > CMPA and configure AQCTLA.CAU to toggle / clear / set depending upon your requirement. This should change the dutycycle. Please find more information about this in AQCTLA register description in PWM chapter of TRM.

Regards,
Manoj

My code now reads as follows:

"

EALLOW;
GpioCtrlRegs.GPAMUX1.bit.GPIO2 = 1; // Configure GPIO4 as EPWM3A
CpuSysRegs.PCLKCR2.bit.EPWM2 = 1; //ePWM clock enabled
CpuSysRegs.PCLKCR0.bit.TBCLKSYNC = 0; //ePWM clock gated
EPwm2Regs.TBCTL.bit.CTRMODE = 2; //ePWM up-down count
EPwm2Regs.TBPRD = 100000; //ePWM period = 250 ePWM Clocks = 500 SYSCLKs
EPwm2Regs.AQCTLA.bit.PRD = 3; //toggle GPIO4 on ePWM period match
EPwm2Regs.AQCTLA.bit.CAU = 3;
CpuSysRegs.PCLKCR0.bit.TBCLKSYNC = 1; //start ePWM clock
EPwm2Regs.TBCTL.bit.FREE_SOFT = 3; //ePWM free run
EPwm2Regs.CMPA.all = 75000;
EDIS;"

I have set TBPRD to be higher than CMPA, set TBCTL to up-down count, and set AQCTLA to toggle the signal. I still am unable to change the duty cycle.

Am I writing to the correct register? Right now, I am trying to set the duty cycle with "EPwm2Regs.CMPA.all = 75000;".

Hi Derek,

Have a look in the documentation and find the field width, in bits, of TBPRD and CMPA; I am pretty sure these are currently out-of-range.

I am currently looking up the field width in the technical reference manual.

In the mean time, I feel that "EPwm2Regs.CMPA.all" may not be the correct register to set the duty cycle. Can you verify whether it is? If it's not, which register should I be writing to?

Hi Derek,

Either CMPA or CMPB would be a good choice to control the duty cycle. With CMPA, it would be something along the lines of:

*TBPRD match sets the output state high
*CMPA match sets the output state low (or toggle would work too)

And, as previously mentioned, CMPA needs to be less than TBPRD and both need to be small enough values to fit in their registers.

Right now I have TBPRD set to 1000, and CMPA set to 250. In theory this should give me a 25% duty cycle, but it remains a perfect 50%.

What about the".all" suffix I'm using? (CMPA.all) Is this the correct suffix?

No matter what value I set CMPA to, the duty cycle doesn't change. Is something preventing CMPA from affecting the PWM?