Unusual timer behavior on LPC-2378

I have an LPC-2378 (Rev -) running at 72MHz. I have the TMR0 prescaler set to 71 so that I get 1uS increments of the timer. I have it configured to reset and generate an interrupt. In the interrupt handler, when I load the value from T0TC (the actual counter), I get the value that was in the counter when the interrupt was fired, not the value of 0 that I expected it to contain from being reset. However, a few instructions later (about 20), the counter becomes 0. It also increments to 1 after only a few more instructions indicating that the prescaler was being loaded with a value other than 0 to correct things. Anybody know exactly what's happening and where it's documented?

Reply to
Anthony Fremont
Loading thread data ...

Following up, I think I get it now; I was being dense. The ISR is triggered as soon as a the match occurs between T0TC (count register) and T0MR0 (match register). It seems the prescaler (T0PC) still has to count thru another full cycle (72 CCLKs) before it all rolls over and the count register (T0TC) is reset to 0.

Now I need to figure out why it's taking 21 clocks (CCLK) to execute 6 instructions. I'm running from RAM, so this seems really wrong. I'm reading the prescale register during the ISR three times in a row. Each read using unoptomized C code takes 6 assembly instructions, the value in the prescale register [increments every CCLK] in increasing by exactly 21 each time I read it. How can this be? I feel cheated. Here's the code the compiler (GCC) generates:

57 void __attribute__ ((interrupt("IRQ"))) sample_accelerometer(void) {

- 0x400007a4 : stmdb sp!, {r1, r2, r3} 58 59 TEMP1=T0PC;

- 0x400007a8 : mov r3, #-536870912 ; 0xe0000000

- 0x400007ac : add r3, r3, #16384 ; 0x4000

- 0x400007b0 : add r3, r3, #16 ; 0x10

- 0x400007b4 : ldr r2, [r3]

- 0x400007b8 : ldr r3, [pc, #596] ; 0x40000a14

- 0x400007bc : str r2, [r3] 60 TEMP2=T0PC;

- 0x400007c0 : mov r3, #-536870912 ; 0xe0000000

- 0x400007c4 : add r3, r3, #16384 ; 0x4000

- 0x400007c8 : add r3, r3, #16 ; 0x10

- 0x400007cc : ldr r2, [r3]

- 0x400007d0 : ldr r3, [pc, #576] ; 0x40000a18

- 0x400007d4 : str r2, [r3] 61 TEMP3=T0PC;

- 0x400007d8 : mov r3, #-536870912 ; 0xe0000000

- 0x400007dc : add r3, r3, #16384 ; 0x4000

- 0x400007e0 : add r3, r3, #16 ; 0x10

- 0x400007e4 : ldr r2, [r3]

- 0x400007e8 : ldr r3, [pc, #556] ; 0x40000a1c

- 0x400007ec : str r2, [r3]

Reply to
Anthony Fremont

It seems that you do not have any optimization active.

Compile again with -O2 or -Os.

Which version of GCC?

--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio

I compile without optimization for debugging. After some more testing with straight assembler, it turns out that accessing the timer registers (TxTC and TxPC) incurs a huge penalty. All other instructions accessing internal SRAM execute in the proper number of cycles. Acessing the timer registers on the APB takes 13 CCLK cycles for an LDR instruction. Anyone know why that might be?

Reply to
Anthony Fremont

'm

:

with

rnal

ers

y

Could be a syncronization delay across the ahb-apb bridge, would make sense if the peripherals were running at a slower clock than the core. But if CCLK and PCLK is the same I don't see why it need to be more that at most a few cycles

does it change if you change the pclk?

-Lasse

Reply to
langwadt

Yes it takes even more cycles if you slow PCLK down. Everything on the APB seems take at least 10 extra cycles, not counting the normal cycle count for the instruction. The RTC area is even worse though, it adds a variable number of cycles taking from 25 to 28 cycles to execute a single LDR. That's not a good thing. Someone else verified that the lpc-2368 has the same characteristics. I don't know about other models.

Reply to
Anthony Fremont

I haven't looked much the lpc2xxx, but I can sort of understand accessing an rtc being slow, parts of it runs at a kHz clock and it might be build with slower transistors to save power in sleepmode.

sounds like the complaints about the early lpc's a 60MHz mcu couldn't even toggle a gpio with 1MHz

-Lasse

Reply to
langwadt

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.