On Thu, 07 Jul 2011 22:32:46 -0500, "navman"
<naveen_pn@n_o_s_p_a_m.yahoo.com> wrote:

>>The external interrupts each have a glitch filter.  This could be a large 
>
>>portion of your "lag".
>
>The glitch filters add just 5ns lag according to the datasheet. 
>
>>Have you tried talking to your NXP FAE?
>
>I've contacted NXP and awaiting their response. 

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

-- 
Rich Webb     Norfolk, VA

>The external interrupts each have a glitch filter.  This could be a large 

>portion of your "lag".

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

>Have you tried talking to your NXP FAE?

I've contacted NXP and awaiting their response. 

	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

Op Thu, 23 Jun 2011 19:50:41 +0200 schreef navman  
<naveen_pn@n_o_s_p_a_m.yahoo.com>:
> 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.

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.)

On 7/6/2011 10:49 AM, navman wrote:
> - 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 http://www.EmbeddedRelated.com

Have you tried talking to your NXP FAE?

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

- 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 http://www.EmbeddedRelated.com

navman <naveen_pn@n_o_s_p_a_m.yahoo.com> wrote:
> Is there any workaround/ideas to circumvent this lag? I feel cheated by the
> Cortex-M3 spec which claims "12 cycles interrupt latency".         

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

-a

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 <naveen_pn@n_o_s_p_a_m.yahoo.com> wrote:
> 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 http://www.EmbeddedRelated.com

On 06/26/2011 06:26 AM, navman wrote:
> Is there any workaround/ideas to circumvent this lag? I feel cheated by the
> Cortex-M3 spec which claims "12 cycles interrupt latency". 	

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

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 http://www.EmbeddedRelated.com

On Fri, 24 Jun 2011 05:54:26 -0500, "navman"
<naveen_pn@n_o_s_p_a_m.yahoo.com> wrote:

>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:
>http://support.code-red-tech.com/CodeRedWiki/RDB1768cmsisExampleProjects
>
>- The code enables the interrupts sends a "Started" message to UART and
>stays inside  while(1). 	   

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