topic PWM issues - LPC1769 in LPCXpresso IDE

PWM issues - LPC1769

lpcware — Thu, 16 Jun 2016 01:21:55 GMT

Content originally posted in LPCWare by nbaer89 on Wed Nov 16 12:40:51 MST 2011
I am trying to get PWM control servo motors for a project I am working on however I can only get one of the pwm pins to change its pulse width.

The PWM_Init function below works fine, it sets each pin to the 1.5ms pulsewidth I need and the servos hold their center position.

void PWM_Init( void )
{

  LPC_PINCON->PINSEL4 &= ~0x000000FF; // Clear P2.0~3 Pins
  LPC_PINCON->PINSEL4 |=  0x00000055; // Set pins for PWM

  LPC_PWM1->TCR = 0x00000002;   /* Counter Reset */
  LPC_PWM1->PR  = 0x18;        /* Count Frequency = Peripheral clock / (24+1) = [1 Mhz]*/
  LPC_PWM1->MCR = (1<<1);      /* Reset TC on Match 0 */
  LPC_PWM1->MR0 = 20000;  /* set PWM cycle */
  LPC_PWM1->MR1 = 1500;
  LPC_PWM1->MR2 = 1500;
  LPC_PWM1->MR3 = 1500;
  LPC_PWM1->MR4 = 1500;

  /* all PWM latch enabled */
  LPC_PWM1->LER = LER0_EN | LER1_EN | LER2_EN | LER3_EN | LER4_EN;
  return;
}

However when I call PWM_Set to change the pulsewidth of a servo I can only get the PWM1[2] pulsewidth(set with case CH_ELEVATOR) to change, the others will keep the initial pulsewidth.

void PWM_Set( uint32_t channelNum, uint32_t pulseWidth )
{

  // Set new pulse width to match register and enable latch
  switch ( channelNum )
  {
    case CH_ROLL :
      LPC_PWM1->MR1 = pulseWidth; // Set match register 1 value
      LPC_PWM1->LER = (1<<1); // Enable latch 1
      break;
    case CH_ELEVATOR :
      LPC_PWM1->MR2 = pulseWidth; // Set match register 2 value
      LPC_PWM1->LER = (1<<2); // Enable latch 2
      break;
    case CH_THROTTLE :
      LPC_PWM1->MR3 = pulseWidth; // Set match register 3 value
      LPC_PWM1->LER = (1<<3); // Enable latch 3
      break;
    case CH_RUDDER :
      LPC_PWM1->MR4 = pulseWidth; // Set match register 4 value
      LPC_PWM1->LER = (1<<4); // Enable latch 4
      break;
  }
  return;
}

Am I doing something wrong here? The code is running in freeRTOS however I don't think that is the cause of the issue. Any help will be greatly appreciated, thanks.

Re: PWM issues - LPC1769

lpcware — Thu, 16 Jun 2016 01:21:56 GMT

Content originally posted in LPCWare by Ex-Zero on Wed Nov 16 13:04:57 MST 2011
Did you use debugger to check if your function PWM_Set is selecting the correct case (or always case CH_ELEVATOR)?

Re: PWM issues - LPC1769

lpcware — Thu, 16 Jun 2016 01:21:57 GMT

Content originally posted in LPCWare by nbaer89 on Wed Nov 16 13:27:11 MST 2011
Yeah it steps through the cases properly. Right now I only call the function for the first two cases. But I think I have found the problem, I was setting the latch values instead of ORing them so when I called pitch it set the latch register for only latch 2 before the first latch was utilized.

Re: PWM issues - LPC1769

lpcware — Thu, 16 Jun 2016 01:21:58 GMT

Content originally posted in LPCWare by Ex-Zero on Wed Nov 16 13:33:21 MST 2011
Yes, of course :rolleyes:

I usually write all PWM latch bits even if I change only one of them. It's faster than reading and writing :)

Re: PWM issues - LPC1769

lpcware — Thu, 16 Jun 2016 01:21:58 GMT

Content originally posted in LPCWare by raymond.centek on Fri Jan 20 00:57:43 MST 2012
I also encountered the similar problem.
According to the code at "lpc17xx_pwm.c" version 2.1 (31-3-2011), the method to write one Match Register (void PWM_ConfigMatch()) is write MR and "OR" the corresponding Latch to high.
In my case, when event occured, I need to change two PWM value. The first method I tried is to call "PWM_ConfigMatch" twice only. Using this method sometimes will cause the channel output full power, i.e., always output high. I investigated the registers about PWM when it goes wrong, but the values were what I assigned to.
The second method which I currently use to avoid the problem is using the function "PWM_MultiMatchUpdate" in PWM library. However, I need to assign the array of struct, which I think is an inefficient way to do.
I mentioned the pwm library is because I think if the official library(though I'm not sure if it is really the official library from NXP. I assume it is) use this method as well, the MCU should be support this method.
I want to know if the second method is the only method I can use to avoid the problem, or there is something need to do if I want to use method one.