topic Re: mystery delay using TMR32B0 in LPCXpresso IDE

mystery delay using TMR32B0

lpcware — Wed, 15 Jun 2016 23:58:56 GMT

Content originally posted in LPCWare by mfph on Tue May 31 18:14:02 MST 2011
Hello All,

I am trying to generate a 'high' pulse on P0.1 (using TMR32B0) of the LPCXpresso LPC1114 board running at 48 MHz with release build. The problem is that I am seeing a pulse several cycles longer than expected.

My code is this:

void TMG_Send()
{
    //LPC_TMR32B0->EMR |= (1<<2);            // Set pin high
    LPC_TMR32B0->EMR = (1<<8) | (1<<2);        // Clear pin on match, Set pin high.. faster than read-modify-write
    LPC_TMR32B0->TCR = (1<<0);                // Enable timer 0
}

void TMG_Init()
{
    LPC_SYSCON->SYSAHBCLKCTRL |= (1<<9);    // Gate AHB clock to CT32B0 (32 bit counter/timer 0)
    LPC_IOCON->PIO0_1 = (1<<1);                // Assign CT32B0_MAT2 to P0.1
    LPC_TMR32B0->TCR = (1<<1);                // Disable timer 0 and reset TC and PC
    LPC_TMR32B0->TCR = 0;                    // Release TC and PC from reset
    LPC_TMR32B0->PR = 0;                    // Prescale counter = 0 = div by 1
    LPC_TMR32B0->MCR = (1<<7) | (1<<8);        // Reset and stop TC on match MR2R
    LPC_TMR32B0->EMR = (1<<8);                // Clear pin on match, also set output to zero
    LPC_TMR32B0->MR2 = 10; //960;                    // ~20us
}

Operation is simple. I initialize the timer, and thereafter simply run TMG_Send() whenever I want to output a pulse. Above I have set match value to 10, which should give 11 cycles = ~229.17ns time.

When I look at the output assembly listing, I have:

12:../src/timing.c ****     //LPC_TMR32B0->EMR |= (1<<2);            // Set pin high
  13:../src/timing.c ****     LPC_TMR32B0->EMR = (1<<8) | (1<<2);        // Clear pin on match, Set pin high.. faster than read-modify
  31                      .loc 1 13 0
  32 0000 034B             ldr    r3, .L3
  33 0002 8222             mov    r2, #130
  34 0004 5200             lsl    r2, r2, #1
  35 0006 DA63             str    r2, [r3, #60]
  14:../src/timing.c ****     LPC_TMR32B0->TCR = (1<<0);                // Enable timer 0
  36                      .loc 1 14 0
  37 0008 0122             mov    r2, #1
  38 000a 5A60             str    r2, [r3, #4]
.....
  44                  .L3:
  45 0010 00400140         .word    1073823744

To me this looks as expected. It shows that there should be a 2 count delay between setting the pin high and enabling the timer. So one would expect to see a delay of ~270.83ns rather than 'ideal' ~229.17ns, However when I measure this pulse on an oscilloscope I see ~374.8ns which corresponds to an extra 5 cycles on top of this. Does anyone know what the source of this extra delay might be?

Regards
mfph

Re: mystery delay using TMR32B0

lpcware — Wed, 15 Jun 2016 23:58:57 GMT

Content originally posted in LPCWare by gbm on Tue May 31 23:29:21 MST 2011
Peripheral access is not immediate - the peripheral interface is slower than the CPU. Some internal "wait states" are inserted, causing the delay you can see.

Re: mystery delay using TMR32B0

lpcware — Wed, 15 Jun 2016 23:58:57 GMT

Content originally posted in LPCWare by Polux rsv on Wed Jun 01 01:20:46 MST 2011
Unless code should run during this pulse, generating so short pulses is often better with

[B]DisableInterrupts();
[/B][B]SetbitHigh();
for (i=0;i<value;i++);[/B]
[B]SetbitLow();
EnableInterrupts();

[/B]Adjust value to reach the exact length. And timing could change depending on optimization level.

Obviously, using a hardware timer give constant timings.

Angelo

Re: mystery delay using TMR32B0

lpcware — Wed, 15 Jun 2016 23:58:58 GMT

Content originally posted in LPCWare by mfph on Wed Jun 01 13:44:11 MST 2011

Quote: gbm
Peripheral access is not immediate - the peripheral interface is slower than the CPU. Some internal "wait states" are inserted, causing the delay you can see.

Many thanks for your reply.

Should I be looking at NXP-specific or ARM documents to find information on predicting these delays? The NXP user manual chapters 15 and 16 provide no information on how to time using capture or match functions taking these peripheral waits into account, which for the given topic is not much use. It would make sense to provide a calculation, reference or at least a hint!

Essentially I want to send a 'pulse', wait a bit, then start timing for a capture event but I'm not able to determine where all the delays are caused or how to predict them.

Re: mystery delay using TMR32B0

lpcware — Wed, 15 Jun 2016 23:58:59 GMT

Content originally posted in LPCWare by mfph on Wed Jun 01 13:48:29 MST 2011

Quote: Polux rsv
Unless code should run during this pulse, generating so short pulses is often better with

[B]DisableInterrupts();
[/B][B]SetbitHigh();
for (i=0;i<value;i++);[/B]
[B]SetbitLow();
EnableInterrupts();

[/B]Adjust value to reach the exact length. And timing could change depending on optimization level.

Obviously, using a hardware timer give constant timings.

Angelo

Hi Angelo, yes I may end up doing this to free up timer resource as my other timing tasks are more critical. Thanks for the suggestion.

Re: mystery delay using TMR32B0

lpcware — Wed, 15 Jun 2016 23:58:59 GMT

Content originally posted in LPCWare by gbm on Wed Jun 01 14:21:10 MST 2011
If you need precise timing, use PWM in one-shot mode.