This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Tiva C Hardware PWM / FaultISR problem

Im trying to use the Hardware PWM from Driverlib to test my rgb LEDs a bit.

my problem is i m alwasy getting into the FaultISR when im initialising PWM at ->GPIOPinTypePWM(GPIO_PORTF_BASE, GPIO_PIN_0);

int main(void) {

SysCtlClockSet(SYSCTL_SYSDIV_5|SYSCTL_USE_PLL|SYSCTL_XTAL_16MHZ|SYSCTL_OSC_MAIN);
PWM_init();
while(1){}
}

void PWM_init(void){

SysCtlPWMClockSet(SYSCTL_PWMDIV_1); //Set the PWM clock to the system clock

//
// The PWM peripheral must be enabled for use.
//
SysCtlPeripheralEnable(SYSCTL_PERIPH_PWM1);

//
// For this example PWM0 is used with PortB Pins 6 and 7. The actual port
// and pins used may be different on your part, consult the data sheet for
// more information. GPIO port B needs to be enabled so these pins can be
// used.
// TODO: change this to whichever GPIO port you are using.
//
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);

//
// Configure the GPIO pin muxing to select PWM functions for these pins.
// This step selects which alternate function is available for these pins.
// This is necessary if your part supports GPIO pin function muxing.
// Consult the data sheet to see which functions are allocated per pin.
// TODO: change this to select the port/pin you are using.
//
GPIOPinConfigure(GPIO_PF0_M1PWM4);
GPIOPinConfigure(GPIO_PF1_M1PWM5);
GPIOPinConfigure(GPIO_PF2_M1PWM6);
GPIOPinConfigure(GPIO_PF3_M1PWM7);

//
// Configure the GPIO pad for PWM function on pins PB6 and PB7. Consult
// the data sheet to see which functions are allocated per pin.
// TODO: change this to select the port/pin you are using.
//
GPIOPinTypePWM(GPIO_PORTF_BASE, GPIO_PIN_0);
GPIOPinTypePWM(GPIO_PORTF_BASE, GPIO_PIN_1);
GPIOPinTypePWM(GPIO_PORTF_BASE, GPIO_PIN_2);
GPIOPinTypePWM(GPIO_PORTF_BASE, GPIO_PIN_3);

//
// Set the PWM period to 250Hz. To calculate the appropriate parameter
// use the following equation: N = (1 / f) * SysClk. Where N is the
// function parameter, f is the desired frequency, and SysClk is the
// system clock frequency.
// In this case you get: (1 / 250Hz) * 16MHz = 64000 cycles. Note that
// the maximum period you can set is 2^16 - 1.
// TODO: modify this calculation to use the clock frequency that you are
// using.
//

//
// Configure the PWM0 to count up/down without synchronization.
// Note: Enabling the dead-band generator automatically couples the 2
// outputs from the PWM block so we don't use the PWM synchronization.
//
PWMGenConfigure(PWM1_BASE, PWM_GEN_0, PWM_GEN_MODE_DOWN |
PWM_GEN_MODE_NO_SYNC);


PWMGenPeriodSet(PWM1_BASE, PWM_GEN_0, 64000);

//
// Set PWM0 PD0 to a duty cycle of 25%. You set the duty cycle as a
// function of the period. Since the period was set above, you can use the
// PWMGenPeriodGet() function. For this example the PWM will be high for
// 25% of the time or 16000 clock cycles (64000 / 4).
//
PWMPulseWidthSet(PWM1_BASE, PWM_OUT_4,PWMGenPeriodGet(PWM0_BASE, PWM_OUT_4) /8);
PWMPulseWidthSet(PWM1_BASE, PWM_OUT_5,PWMGenPeriodGet(PWM0_BASE, PWM_OUT_5) /4);
PWMPulseWidthSet(PWM1_BASE, PWM_OUT_6,PWMGenPeriodGet(PWM0_BASE, PWM_OUT_6) /2);
PWMPulseWidthSet(PWM1_BASE, PWM_OUT_7,PWMGenPeriodGet(PWM0_BASE, PWM_OUT_7));

//
// Enable the dead-band generation on the PWM0 output signal. PWM bit 0
// (PD0), will have a duty cycle of 25% (set above) and PWM bit 1 will have
// a duty cycle of 75%. These signals will have a 10us gap between the
// rising and falling edges. This means that before PWM bit 1 goes high,
// PWM bit 0 has been low for at LEAST 160 cycles (or 10us) and the same
// before PWM bit 0 goes high. The dead-band generator lets you specify
// the width of the "dead-band" delay, in PWM clock cycles, before the PWM
// signal goes high and after the PWM signal falls. For this example we
// will use 160 cycles (or 10us) on both the rising and falling edges of
// PD0. Reference the datasheet for more information on dead-band
// generation.
//
PWMDeadBandEnable(PWM1_BASE, PWM_GEN_0, 160, 160);

//
// Enable the PWM0 Bit 0 (PD0) and Bit 1 (PD1) output signals.
//
PWMOutputState(PWM1_BASE, PWM_OUT_4_BIT | PWM_OUT_5_BIT|PWM_OUT_6_BIT|PWM_OUT_7_BIT, true);

//
// Enables the counter for a PWM generator block.
//
PWMGenEnable(PWM1_BASE, PWM_GEN_0);

}

  • Again - PF0 continues its torment!  There must be a better way to alert new users...  (suspect "some" red-ink remains from NRND - plastered atop all M3 manuals)  If only such "care" could extend to default NMI pins...

    That pin - and one other - default as NMI - and cannot be "escaped" into other usage w/out first being "unlocked."  (how delightful)

    Most (all?) of the Eval boards avoid use of PF0 - or provide proper unlocking and re-config'ing.  Appears not the case - your usage...

    You have two choices - review GPIO section of MCU manual - you'll note the warnings re: PF0.  Attention can then turn to unlock procedure.

    Or - avoid use of PF0 (and its equally evil, NMI "twin") and proceed.

    Here's known good PWM set-up config code (just the starter - for "safe pins PB6, PB7): 

         ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_PWM0);
        //
        // Make the PWM pins be peripheral function.
        //
         ROM_GPIOPinTypePWM(GPIO_PORTB_BASE, GPIO_PIN_6 | GPIO_PIN_7);
         ROM_GPIOPinConfigure(GPIO_PB6_M0PWM0);
         ROM_GPIOPinConfigure(GPIO_PB7_M0PWM1);

    Here's today's related post - details may be of some benefit... http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/282889.aspx

  • I'm late to the party, but must acknowledge "(suspect "some" red-ink remains from NRND - plastered atop all M3 manuals)" gave me a good laugh!  My kind of humor!

    I am in full agreement that countless hours, world wide, have been wasted due to lack of a few kind, cautionary notes concerning default NMI behavior.  It would be nice to have a concise table of all GPIO pins that have odd personalities - whether not 5V compliant, pullup issues, NM lock, drive capability, etc...

    Thanks again to CB1 for your reliable contributions and gentle documentation suggestions!

     

    Regards,

    Dave

     

  • @ Dave,

    Never too late for your skilled arrival - especially your classification of, "plastered atop" as gentle... 

    If "insanity" describes the endless repetition of a non-productive behavior/process - then the MCU manuals (in their existing form) may so qualify. (at least - in that particular, NMI alert, regard)

    And - you/I/countless others have long noted - and "gently" protested - the clear, "inadequacy" of any/all NMI warnings - as now propagated...

    Our clients in both medicine & defense have long developed far more effective methods to, "sound a precautionary note."  Thus - often such "precautions" appear early (front page) - and often - and even may employ that NRND pen and bold stroke...

    The missile will fly when the stack of specs/code/tech docs grows taller than the missile.  Volume MCU Sales can reasonably be expected to improve when the unending procession of hapless users are, "steered better away" - from an easily predictable - and highly avoidable - usage pitfall...  (even if - and especially if - the suggested "fix" was of, "NIH" origin)

    How stellar - that concept...