LPC2148 ADC Interrupt doesn't get cleared...

Please explain how your ADC interrupt code differs from the ADC interrupt code of the sample code supplied by NXP, the maker of your chip. That difference should also tell you which part of the processor user manual you should consider spending some more time with.

For clearing interrupt you huave to put isr like.....

unsigned int status,A0_1;
void ADC_Init()                 //This function inits ADC peripheral
{
   VICIntEnable=0x0;

        PINSEL1|= (1<<24);
        AD0CR=(1<<1)|(13<<8)|(1<<21);
        AD0INTEN=(0x00)|(1<<1);
        status0=AD0STAT;
        VICVectAddr9=(unsigned long) ADC0_ISR0;
        VICVectCntl9=0x20|18;
        VICIntEnable=(VICIntEnable) |(1<<18);

}


void __irq ADC0_ISR0(void)
{
  int ad;
  status0=AD0STAT;
  ad=status0 & 0x000000FF;
  switch(ad)
    {case 0x02:
                A0_1 = AD0DR1 ;            //Store converted data
                A0_1= AD0DR1 ;// again read and clear interrupt
                break;
      default :
                break;
     }
   if(ad==0x02)
     A0_1 = (A0_1 >>6);    //result-------every time you need to read it it is updated every  time so use it to display on lcd

    Delay(1);
    VICVectAddr = 0;    // Acknowledge Interrupt

}

void main()
{
//your variables and other codes


 while(1)
  {
   Delay(10);
   AD0CR = (AD0CR&0xFFFFFF00)|(1<<1)|(1<<24);
   Delay(10);
  }
}

Are you sure you found good reference code that suggested that you should make use of delays in an ISR just to waste a bit of processor time?

Thank you very much for your reply. I am really thankful to all of you. I will surely check for the code you have provided and will come to know you about it as soon as possible.

In isr. If you delay don't consider delay than it will sure work bcoz delay is very minor though I am not mension it is of how much and this will sure work I tested it........

Note that you did add a delay without any comment to the reason.

Was it because the read/write delays when interfacing a peripherial can result in a quick acknowledge of the interrupt to have the processor directly make a second interrupt for the same event - all because the VIC still saw the peripherial as needing service?

The delay needed to handle that issue is _very_ short and can be handled much better than calling any delay function. Most often, it's enough to just optimize the order of the source code statements. And obviously, code shouldn't contain any "black magic" without there being proper documentation to remind the original coder - and let other developers understand the reason for any strange-looking code.

Too much people are busy copy/pasting too much black-magic code without having any idea why the code looks like it does - or if it even needs to look like that. So bad code tends to spread like rings on water.

Delay in while(1) is because of the that when new instructions or other contain is added then it also work and it is for the purpose that we have to restart the conversion after getting the first interrupt and delay in is because of read/write delay of controller.....

But the process of restarting the conversion depends on your application....sometimes it needs immediate some tile it needs after few seconds....

you can also debug this code and find out you can easily got your ways to come forward...

Delayed restart of conversion really should not be implemented by hanging the ISR.

The whole idea with ISR is to make sure that the ADC can perform the magic concurrently with normal software processing.

Sometimes, it's enough to slow down the clock rate to the ADC to adjust the number of samples/second the ADC will manage. The next option is to have a timer ISR that decides when it's time to start a conversion. There are lots of options, but sleeping in an ISR is really not the recommended route to go since that hurts the reaction to other interrupts that happens to have a lower priority - or hurts all other ISR in case you don't allow nested interrupts.