1. Home
  2. Embedded Programming
  3. LPC1768 EXT0 interrupt huge lag

LPC1768 EXT0 interrupt huge lag

Hi, I've setup LPC1768 for external falling edge interrupt on EINT0 pin and in the interrupt handler, I just clear the interrupt flag and make a pin (P0.0) low and immediately high again. When I check the EINT0 pin and the output pin P0.0 on an oscilloscope, there is a huge lag, about 520ns between the falling edge of EINT0 & the P0.0 becoming low.

I use the LPCxpresso complier and I confirm the LPC is running at full

100MHz (from the clkout pin).

Here is the interrupt handler:

======================================================= void EINT0_IRQHandler (void) { // Clear interrupt LPC_SC->EXTINT = EINT0_CLR;

LPC_GPIO0->FIOCLR0|=0x01;//make P0.0 low LPC_GPIO0->FIOSET0|=0x01;//make P0.0 high } =======================================================

Here is the disassembly from the compiler:

=======================================================

000001d8 :

void EINT0_IRQHandler (void) { // Clear interrupt LPC_SC->EXTINT = EINT0_CLR; 1d8: 4b06 ldr r3, [pc, #24] (1f4 ) 1da: 2201 movs r2, #1 1dc: f8c3 2140 str.w r2, [r3, #320]

LPC_GPIO0->FIOCLR0|=0x01;//make P0.0 low

1e0: 4a05 ldr r2, [pc, #20] (1f8 ) 1e2: 7f13 ldrb r3, [r2, #28] 1e4: f043 0301 orr.w r3, r3, #1 ; 0x1 1e8: 7713 strb r3, [r2, #28] LPC_GPIO0->FIOSET0|=0x01;//make P0.0 high 1ea: 7e13 ldrb r3, [r2, #24] 1ec: f043 0301 orr.w r3, r3, #1 ; 0x1 1f0: 7613 strb r3, [r2, #24] } 1f2: 4770 bx lr =======================================================

I cannot find out why it is taking so long. The number of instructions do not add up to anywhere close to 500ns. Any ideas?

--------------------------------------- Posted through

formatting link

Reply to
navman
Loading thread data ...

I don't know why it's taking so long, but you don't need to do a read-modify-write on the CLR and SET ports. The point of those ports is that you can clear and set bits by just writing the mask to them.

So FIOCLR0 = 0x01 will clear a bit, and FIOSET0 = 0x01 will set it.

Do you have other interrupts running ?

Reply to
Arlet Ottens

How long does it take to save the processor state before entering the ISR?

-- Roberto Waltman

[ Please reply to the group. Return address is invalid ]
Reply to
Roberto Waltman

strb r3, [r2,

strb r3, [r2,

You are going to loose 12 cycles just to get into the ISR. Plus another

4ns (or more) at the interrupt pin to recoginze the level. If you are using the standard LPCXpresso options your flash config is probably 6, so that is 60ns to read in a flash block. But that should only be on the first time into the ISR if nothing else is running to flush the flash cache. Driving the P0 io pin is going to take 3 to 5 ns plus what ever load you have on it.

Still does not add up to 540 but start looking at external factors. Is your main loop just sitting in a loop waiting for the external interrupt or did you cob this test code into a more complex system?

Reply to
Joe Chisolm

The Cortex-M3 does that automatically, and IIRC takes 12 cycles if the RAM runs at full speed. At 100 MHz there will be some added latency from flash wait states (so if latency is critical you may not want to run these chips at full speed). The LPC1700 also has a prefetch buffer intended to hide some of the flash latency, but I don't know if it has any impact on interrupt latencies.

-a

Reply to
Anders.Montonen

Just to answers questions above,

- No other interrupts are enabled.

- Its a standard LPCxpresso demo code modified to make P0.0 low-high inside the interrupt. It is the "RDB1768cmsis_ExtInt" example found here:

formatting link

- The code enables the interrupts sends a "Started" message to UART and stays inside while(1).

--------------------------------------- Posted through

formatting link

Reply to
navman

FWIW, I'm seeing comparable delay on a 96 MHz LPC1768 with Rowley's CrossWorks compiler. I'd guess that it's a consequence of flushing the pipeline, though it would be interesting to see numbers from a non-gcc based compiler.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

Is there any workaround/ideas to circumvent this lag? I feel cheated by the Cortex-M3 spec which claims "12 cycles interrupt latency".

--------------------------------------- Posted through

formatting link

Reply to
navman

Try putting the ISR in RAM. Maybe the delay is caused by the flash access time.

Reply to
Arlet Ottens

Strictly for learning, you might use your assembler and set an interupt that puts a single pulse on one pin then exits. Put a loop in the main code that does nothing toggle another pin forever. Then use a scope to view both pins and, hopefully, get a clear idea of the delays both into and out of an interupt.

Hul

navman wrote:

Reply to
dbr

In addition to placing the ISR in RAM, check the peripheral clocks.

-a

Reply to
Anders.Montonen

- Placed the ISR in RAM (and verified it is in RAM in the map file)

- Remapped interrupt vector to RAM

- Ensured that the peripheral clock speed is same as core clock.

Still getting about 400ns lag from the falling edge to toggling of IO pin inside the interrupt. Can't figure out how to get the "12 cycles" lag as advertised for Cortex M3. Any more ideas?

--------------------------------------- Posted through

formatting link

Reply to
navman

Have you tried talking to your NXP FAE?

--
Rob Gaddi, Highland Technology
Email address is currently out of order
Reply to
Rob Gaddi

Op Thu, 23 Jun 2011 19:50:41 +0200 schreef navman :

The external interrupts each have a glitch filter. This could be a large portion of your "lag".

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
(Remove the obvious prefix to reply.)
Reply to
Boudewijn Dijkstra

The glitch filters add just 5ns lag according to the datasheet.

I've contacted NXP and awaiting their response.

--------------------------------------- Posted through

formatting link

Reply to
navman

FWIW, I tried the external interrupt experiment on an STM32 CM3 with similar (500-ish ns) results. Architectural issue?

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

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.