Hi all,
I have a custom made PCB with a LM3S6753 and run into problems configuring the PWM.
The CPU runs, ethernet works, etc, so I don't assume that there is a fault in the hardware.
I use the example from Stellarisware which configures PWM0 and PWM1 pin. This runs fine.
I am going to use the PWM2 pin in my application and so I modified the example code like below
At the PWMGenConfigure, the CPU gives me a fault and is caught in the FaultISR IRQ.Any idea what's wrong with it?When I simply use the example with PWM0 and GPIO F0 and D1, it is working.Best regards,Rainer
void prvSetupHardware( void ) { /* If running on Rev A2 silicon, turn the LDO voltage up to 2.75V. This is a workaround to allow the PLL to operate reliably. */ if( DEVICE_IS_REVA2 ) { SysCtlLDOSet( SYSCTL_LDO_2_75V ); } unsigned long ulPeriod; // // Set the clocking to run directly from the crystal. // SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN | SYSCTL_XTAL_8MHZ); SysCtlPWMClockSet(SYSCTL_PWMDIV_1); // // Enable the peripherals used by this example. // just for testing, I enabled all GPIO ports and PWM0 and 1 SysCtlPeripheralEnable(SYSCTL_PERIPH_PWM1); SysCtlPeripheralEnable(SYSCTL_PERIPH_PWM0); SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB); SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA); SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOC); SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD); SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOE); SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF); SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOG); SysCtlDelay(5); // // Set GPIO B0 as PWM pin. They are used to output the PWM2 signal // GPIOPinTypePWM(GPIO_PORTB_BASE, GPIO_PIN_0); // // Compute the PWM period based on the system clock. // ulPeriod = SysCtlClockGet() / 440; // // Set the PWM period to 440 (A) Hz. // PWMGenConfigure(PWM1_BASE, PWM_GEN_0, PWM_GEN_MODE_UP_DOWN | PWM_GEN_MODE_NO_SYNC); PWMGenPeriodSet(PWM1_BASE, PWM_GEN_0, ulPeriod); // // Set PWM0 to a duty cycle of 25% and PWM1 to a duty cycle of 75%. // PWMPulseWidthSet(PWM1_BASE, PWM_OUT_2, ulPeriod / 4); // // Enable the PWM0 and PWM1 output signals. // PWMOutputState(PWM1_BASE, PWM_OUT_2_BIT, true); // // Enable the PWM generator. // PWMGenEnable(PWM1_BASE, PWM_GEN_0); while(1); return; }
In line 23, you enable PWM0;
SysCtlPeripheralEnable(SYSCTL_PERIPH_PWM0);
But in line 47 and after, you use PWM1_BASE;
PWMGenConfigure(PWM1_BASE, PWM_GEN_0, PWM_GEN_MODE_UP_DOWN | PWM_GEN_MODE_NO_SYNC);
Agree w/Marc's comment re: PWM_GEN_1. However - believe further that your MCU is sufficiently advanced (pin mux wise) that you require a GPIOPinConfigure() for each/every pin - bound for PWM use. I see plentiful use of PWMPinType() - but zero use of GPIOPinConfigure!
You do PWMGenConfigure() - but I do not believe that fuction is sufficient to operate w/out GPIOPinConfigure().
Beware that you must employ only those pins designated w/in a certain PWM Generator. (i.e. PWMGen_0 can only operate upon PWM_0 and PWM_1, PWMGen_1 only upon PWM_2 and PWM_3.) (am on the road - this from memory - may be butchering the designators - thrust is sound though...)
You are very close - you'll have it shortly...
Thanks for your answers
Unfortunately, I messed around with the code formatting. In the first line, right at the end (out of the visible area) there is the PeripheralEnable for PWM1. It is contained in the code, but it doesn't work.
Let me describe it once again, a little more thoroughly
I took the example from Stellarisware, Version 8555, which looks like this
int main(void) { unsigned long ulPeriod; // // Set the clocking to run directly from the crystal. // SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN | SYSCTL_XTAL_8MHZ); SysCtlPWMClockSet(SYSCTL_PWMDIV_1); // // Enable the peripherals used by this example. // SysCtlPeripheralEnable(SYSCTL_PERIPH_PWM0); SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD); SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF); // // Set GPIO F0 and D1 as PWM pins. They are used to output the PWM0 and // PWM1 signals. // GPIOPinTypePWM(GPIO_PORTF_BASE, GPIO_PIN_0); GPIOPinTypePWM(GPIO_PORTD_BASE, GPIO_PIN_1); // // Compute the PWM period based on the system clock. // ulPeriod = SysCtlClockGet() / 440; // // Set the PWM period to 440 (A) Hz. // PWMGenConfigure(PWM0_BASE, PWM_GEN_0, PWM_GEN_MODE_UP_DOWN | PWM_GEN_MODE_NO_SYNC);
Then, I modified it like this
int main(void) { unsigned long ulPeriod; // // Set the clocking to run directly from the crystal. // SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN | SYSCTL_XTAL_8MHZ); SysCtlPWMClockSet(SYSCTL_PWMDIV_1); // // Enable the peripherals used by this example. // SysCtlPeripheralEnable(SYSCTL_PERIPH_PWM1); SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB); // // Set GPIO B0 as PWM pin. // GPIOPinTypePWM(GPIO_PORTB_BASE, GPIO_PIN_0); // // Compute the PWM period based on the system clock. // ulPeriod = SysCtlClockGet() / 440; // // Set the PWM period to 440 (A) Hz. // PWMGenConfigure(PWM1_BASE, PWM_GEN_0, PWM_GEN_MODE_UP_DOWN | PWM_GEN_MODE_NO_SYNC);
The first one works, the second one doesn't.
At the PWMGenConfigure, I get the FaultISR.
Best regards,
Rainer
I must confess, I’m not really confident with the PWM generator, but I looked into the API, and I think I found the problem;
SYSCTL_PERIPH_PWM0, is the PWM0 block, which can contain max 4 generators(in your case it’s 3), also a µC can only contain a maximum of 2 PWM blocks(yours only has 1), or SYSCTL_PERIPH_PWM0 & SYSCTL_PERIPH_PWM1
This means you need to use PWM0_BASE, for all your configurations, and use PWM_GEN_1, in your case.
It’s what cb1_mobile already stated…
Marc,
thanks for your answer. It seems to me you're sitting there all the time, only waiting for my posts to answer them incredibly fast!
I confused PWM modules with generators, rather stupid I must admit.
Kind regards,
Glad you solved the PWM issue - however would you be so good to confirm that you did NOT use GPIOPinConfigure() in your code? (as previously suggested - earlier post this thread) GPIOPinConfigure() is not shown in your code postings - we have found its combined use w/ GPIOPinType() to be required - both w/M3 and new M4...
cb1-
The 6753 is a Fury-class device and therefore does not need the GPIOPinConfigure calls.
Regards,
Sue
HI,
I hereby solemnly swear, that I did not use any GPIOPinConfigure calls :)
With new facts - now in evidence - case dismissed! (solemn swear especially impactful - however "class" warfare/restriction (Ms Cozart) continues to obscure/frustrate/krazy-make - this poster's dog better look out - green deprived, failed forum participant now seeking tall (class-appropriate) bldg from which to jump...)
StellarisWare spectacularly giveth - however under new (dare say "unfortunate," class regime) - StellarisWare sometimes taketh away... (extreme vigilance - constant MCU "class checking" now required! Grrrr....
aside to jury: (original poster - possibly w/out full class awareness - may have "lucked" into solution as much as this reporter butchered - hoped for "correction!" Caveat Venditor! (especially if such Stellarisware weakness/pitfall (unwanted class vigilance "hoop") persists - long term...) but not to complain.... (much)