PWM code out into the weeds

Very quickly (lunch time, here) how about:

PWMPulseWidthSet(PWM0_BASE, PWM_OUT_6,64000 / 4);

PWMOutputState(PWM0_BASE, PWM_OUT_4_BIT, true);

Might results improve - if these match?

Update: Have now read (& understood) your issue.   While match (above) should occur - that's not root cause.

Have you included pwm.h & sysctl.h? (you should not be including sysctl.c - that should reside w/in driverlib)

Manuals advise that some delay should be inserted between: "SysCtlPeripheralEnable(SYSCTL_PERIPH_PWM0);" and "PWMGenConfigure(PWM0_BASE...)"

Always wise to review code examples, "StellarisWare\examples/peripherals\pwm..."  Should reveal required includes and definitions...

We don't know/use/like CCS - most IDEs require that you "define" both the MCU and its revision.  (key file pin_map.h is segregated by MCU/rev - if you've not adequately defined MCU & rev - this will cause issues...)  Many posts here (this forum) detail this procedure.  (use Search @ top right of page)

You may also employ, "Find in Files" w/in the IDE - seeking "PWM0_BASE," then "PWM_GEN_3."  Ability/inability of the IDE to "find" those will aid in your solution...

 

These are my includes:

#include <stdint.h>

#include <stdbool.h>

#include "inc/hw_memmap.h"

#include "inc/hw_types.h"

#include "driverlib/sysctl.h"

#include "driverlib/gpio.h"

#include"driverlib/pwm.h"

#include"inc\hw_pwm.h"

#include"driverlib/pin_map.h"

Will try the delay next.

Here - the includes from examples\peripherals\pwm\"dead_band.c"

#include "inc/hw_memmap.h"
#include "inc/hw_types.h"
#include "driverlib/pwm.h"
#include "driverlib/gpio.h"
#include "driverlib/sysctl.h"
#include "utils/uartstdio.h"

Don't you also require an #include lx4f.123h5qr.h  ?  (your mcu)

Note that you have these!  Is your version of Stellaris/rebrand Ware current?  Have you properly "told" your IDE of MCU ID & Rev? 

Leaning to an IDE set-up issue - and have no experience w/your IDE...

Added the delay and the problem persists. Here is the new code:

void PWM_Setup(void)

{

 SysCtlPWMClockSet(SYSCTL_PWMDIV_1);

 SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOC);  

GPIOPinConfigure(GPIO_PC4_M0PWM6);  

GPIOPinTypePWM(GPIO_PORTC_BASE, GPIO_PIN_4);

 SysCtlPeripheralEnable(SYSCTL_PERIPH_PWM0);  

SysCtlDelay(140000);  

PWMGenConfigure(PWM0_BASE, PWM_GEN_3, PWM_GEN_MODE_UP_DOWN | PWM_GEN_MODE_NO_SYNC);  

PWMGenPeriodSet(PWM0_BASE, PWM_GEN_3, 64000);  

PWMPulseWidthSet(PWM0_BASE, PWM_OUT_6,64000);  

PWMOutputState(PWM0_BASE, PWM_OUT_4_BIT, true);  

PWMGenEnable(PWM0_BASE, PWM_GEN_3);

}

We just crossed!

Don't you also require an #include lx4f.123h5qr.h  ?  (your mcu)

And - while not the root cause - believe this is still needed:

PWMPulseWidthSet(PWM0_BASE, PWM_OUT_6, 64000);  

PWMOutputState(PWM0_BASE, PWM_OUT_4_BIT,  true);  //  my belief is that Gen_3 contains 6_BIT & 7_BIT - PWM_OUT_6_BIT instead needed!  Suspect that you're confusing Port Bit PC4 with PWM_OUT_Bit - and that is not 4_BIT !

If the header for the device were missing, should I not get a compilation error? The code presently compiles without any errors or warnings. Also, while looking at some other code examples such as the quick start rgb, the device header file is not explicitly called out.

Good catch on the PWM_OUT_6_BIT, but my code does not even get there. It gets stuck at PWMGenConfigure. If I comment out that line, it gets stuck at PWMGenPeriodSet, so on, so forth.

That's a good point - the original launchpad employed very stripped-down MCU.

That said - we'd expect that poster would have assumed the responsibility to scan the MCU data manual - when the "weed" diversion arose...

That is indeed the problem. In defense of the "poster" all the training documentation for the launchpad shows the TM4C123GH6PM, which creates some confusion. Also in defense of the "poster", the debug interface does not complain when selecting the wrong device -- most of the other interfaces do.

Thank you for all the help.

Touched a nerve w/that comment - and do agree that the amount & detail of documentation is challenging.  However my intent was not evil - and I believe valid.

Very often in engineering - you'll benefit from "external documentation" - which most often will not exactly overlap nor target your design specifics.  And - we must be careful to identify any critical differences between that "reference" and our design reality.  I believe this is sound practice - and you appear skilled and should benefit from this approach.  This was my intent...   Believe this should be the more lasting/major lesson learned...

While only one "green flag" was hoisted - my "get" of the incorrect PWM parameters had merit.   Code supplied would have failed to PWM - even had a less "crippled" MCU been present...

 

Armando Barbedo said:

In defense of the "poster" all the training documentation for the launchpad shows the TM4C123GH6PM, which creates some confusion. Also in defense of the "poster", the debug interface does not complain when selecting the wrong device -- most of the other interfaces do.

Agree that the TivaWare examples / documentation don't make it obvious how to use TivaWare with the Stellaris Launchpad. What I did in the CCS project was to add the pre-defined name PART_TM4C1233H6PM. This selects the Tiva equivalent part number for the LM4F120H5QR used on the Stellaris Launchpad.

When I tried to compile an example which used PWM1 I then got compile errors due to the PMW1 module pins not being defined in pin_map.h for the chosen device.