LPCXpresso IDEのトピックTimer Library Bug

Timer Library Bug

lpcware — Wed, 15 Jun 2016 21:40:09 GMT

Content originally posted in LPCWare by ElectroNerd on Sun Feb 03 12:08:32 MST 2013
Does the "timer" library in "Examples\NXP\LPC1000\LPC17xx\NXP_LPCXpresso1769_MCB1700_2011-02-11.zip" have a bug for the interval calculation?

[B]My Calculations[/B]

In system_LPC17xx.c, it gives the following defines:

[B]#define PLL0CFG_Val           0x00 00 000B[/B]
#define PLL1_SETUP            1
#define PLL1CFG_Val           0x00000023
[B]#define CCLKCFG_Val           0x00000003[/B]
#define USBCLKCFG_Val         0x00000000
#define PCLKSEL0_Val          0x00000000
[B]#define PCLKSEL1_Val          0x00000000[/B]

[B]#define XTAL        (12000000UL)        /* Oscillator frequency               */[/B]

Which means:

N = 1
M = 12
Fin = 12 MHz
Clock Divide = 4

Fcco = (2 x M x Fin)/N = (2 x 12 x 12e6)/1 = 288 MHz

CCLK (CPU clock) = 288/4 = 72 MHz

PCLK (Peripheral Clock) = CCLK/4 = 18 MHz

[B]timer.c[/B]

// This function delays in milli-seconds (ms)

void delayMs(uint8_t timer_num, uint32_t delayInMs)
{
  if ( timer_num == 0 )
  {
LPC_TIM0->TCR = 0x02;/* reset timer */
LPC_TIM0->PR  = 0x00;/* set prescaler to zero */
LPC_TIM0->MR0 = delayInMs * (9000000 / 1000-1);
LPC_TIM0->IR  = 0xff;/* reset all interrrupts */
LPC_TIM0->MCR = 0x04;/* stop timer on match */
LPC_TIM0->TCR = 0x01;/* start timer */
  
/* wait until delay time has elapsed */
while (LPC_TIM0->TCR & 0x01);
  }
  else if ( timer_num == 1 )
  {
LPC_TIM1->TCR = 0x02;/* reset timer */
LPC_TIM1->PR  = 0x00;/* set prescaler to zero */
LPC_TIM1->MR0 = delayInMs * ([B]9000000[/B] / 1000-1);
LPC_TIM1->IR  = 0xff;/* reset all interrrupts */
LPC_TIM1->MCR = 0x04;/* stop timer on match */
LPC_TIM1->TCR = 0x01;/* start timer */
  
/* wait until delay time has elapsed */
while (LPC_TIM1->TCR & 0x01);
  }
  return;
}

Can someone explain why the code implies a 9 MHz PCLK instead of 18 MHz? Shouldn't it be corrected to:

LPC_TIM1->MR0 = delayInMs * ([B]18000000[/B] / 1000-1);

Also, I have seen "SystemCoreClock" being used as a reference for calculating delay intervals - is this equivalent to CCLK (in this instance, 72 MHz)?

Re: Timer Library Bug

lpcware — Wed, 15 Jun 2016 21:40:10 GMT

Content originally posted in LPCWare by Rob65 on Sun Feb 03 14:26:38 MST 2013

Quote: ElectroNerd
Does the "timer" library in "Examples\

You are not the first to note a bug - and yes, I too think this is a bug (although I have not tested this).

Also note the difference between library and example ...
There is no timer library, just a timer example and that does not even use the delayMs function.
I think that, at some point in time, there was an example setting PCLK to CCLK/8 and then it all fits.

The 'fun' thing is that in that same timer.c file, the init_timer function does take into account that PCLK can be either CCLK/1, /2, /4 or /8 ...

Yes - it's just too bad that these examples (the timer is not the only one) contains bugs making us wonder if we have a problem interpreting the user manual or if there is a bug in the code...

By the way: it's easier to use the systick timer for this kind of delays.

Rob

P.s: you'll find other files named timer.c in the other projects containing a somewhat, yet not completely, similar implementation :confused:

Re: Timer Library Bug

lpcware — Wed, 15 Jun 2016 21:40:10 GMT

Content originally posted in LPCWare by ElectroNerd on Sun Feb 03 18:55:12 MST 2013

Quote: Rob65
You are not the first to note a bug - and yes, I too think this is a bug (although I have not tested this).

Also note the difference between library and example ...
There is no timer library, just a timer example and that does not even use the delayMs function.
I think that, at some point in time, there was an example setting PCLK to CCLK/8 and then it all fits.

The 'fun' thing is that in that same timer.c file, the init_timer function does take into account that PCLK can be either CCLK/1, /2, /4 or /8 ...

Yes - it's just too bad that these examples (the timer is not the only one) contains bugs making us wonder if we have a problem interpreting the user manual or if there is a bug in the code...

By the way: it's easier to use the systick timer for this kind of delays.

Rob

P.s: you'll find other files named timer.c in the other projects containing a somewhat, yet not completely, similar implementation :confused:

It seems as if there is no bug after all. I went ahead and configured TIMER0 for a theoretical 1 ms period and my o'scope showed a 2 ms period! Attached you will find the code that correctly gives 1 ms.

Where does this come in for the calculations?

Rob, I am in the process of creating a timer library for my application, but I may consider using SysTick as a feature.

Re: Timer Library Bug

lpcware — Wed, 15 Jun 2016 21:40:11 GMT

Content originally posted in LPCWare by ElectroNerd on Sun Feb 03 22:19:32 MST 2013
Now I understand why the [I]period[/I] was 2 ms instead of 1 ms. In my main() loop, there is the following code (embellished slightly for explanatory purposes):

// HIGH for 1 ms
led_on(LED_1);
delay_ms(0, DELAY);

// LOW for 1 ms
led_off(LED_1);
delay_ms(0, DELAY);

// Period = HIGH + LOW = 1 ms + 1 ms = 2 ms

Conditions:
[LIST]
[*]CCLK = 120 MHz
[*]PCLK = 30 MHz
[/LIST]

Since we are speaking of a period in terms of a square wave, it would be two times that of the interval calculation.

This would explain the delayMs() function, since they were toggling LEDs and wanted the period properly defined.