Hi!

I am using two interrupt routines. One for PIO Interrupts and one for timer interrupts. In my timer interrupt routine I read the PIO->PDSR register. Is it possible that reading of this register resets PIO->ISR? Both interrupt routines have the same priority so they should not be interrupted by each other.

Thx!

Have you tried disabling the timer interrupt and making sure that the PIO interrupt still fires? I don't think reading the PIO-PDSR should have any effect on the PIO->ISR.

I think so too.

I changed a bit of the code and thought the problem is solved, but now it only takes longer till it appears.

The whole program works with freertos. I try to give you a detailed error description, maybe you an idea I didnt come up with till now. The Error:

After several irqs on a pio line, the irq for this line suddenly doesn't work anymore. I checked the correspondig registers and everything is correct, except that the interrupt pendig register isnt set. When I then trigger an irq on another pio line (same isr), all irqs work again until the same error occurs. I have no idea what the problem is.

It seems as if the interrupt line is disabled after a while of generating interrupts. The duration till the error occurs is different every time. And the error is not solved with a debugger reset. Only a power cut makes it go away, besides triggering another irq.

I am thinking I forgot something in my isr. Is there anything in a PIO isr you have to do besides reading PIO_ISR (I do this at the very beginning) and writing AIC_EOICR at the end of the isr?

Reading the PIO_ISP and writing AIC_EOICR should be the only things you need to end that interrupt. Its interesting that it seems to occur at variable times... Is there any other code that accessed PIO ISR information? Perhaps something is being over written somewhere?

Post your Init codes for the timer and PIO interrupts. Maybe something in there is a little off. Not really sure what that might, but it can't hurt to look.

So here is the initialisation of the PIO interrupts:


and the timer interrupt:


Both clocks get activated elsewhere. I am not reading the PIO->ISR in any other function than the PIO interrupt.

Just found out another thing:

When the error occurs, all interrupts of a PIO port are disabled. The µC only reacts to interrupts at the other PIO port. After one interrupt occured there, interrupts at both ports are recognized.

I wrote a small routine to read out all aic and pio registers before and after the error, and there is no difference between them.

Still working on the problem.

The problem appeared under FreeRTOS. Now I wrote a similar program for use without FreeRTOS and I get the same error.

In my application without FreeRTOS the interrupt is handled different than with FreeRTOS and the problem is the same, so I think either I am forgetting something important in both codes or I have a hardware problem. I tried it with two dev boards and got the same error.

I have no more ideas what could cause this problem. So I still hope someone here can help me!

I think I finally found it, but no solution till now. Heres the problem:

In my ISR I read PIOA->PIO_ISR and PIOB->PIO_ISR. Then I put the values in a Queueue and end the isr with writing to AT91C_BASE_AIC->AIC_EOICR.

I think that the AIC interrupt pending bit is only set when PIO_ISR changes from 0 to 1. PIO_ISR is resettet when read. Now when I am reading PIO_ISR in my isr it is resettet to 0. If another interrupt occurs before writing to AIC_EOICR, the bit in PIO_ISR changes from 0 to 1. Since the isr is still running, the interrupt pending bit is still there. Now when I write to AIC_EOICR, the pending bit gets resettet and since the PIO_ISR bit ist still on 1, no new pending bit is being generated, so no more interrupts from the peripherial. When I generate an interrupt on the other PIO controller, both PIO_ISR registers are being read and after it the interrupts work again until the error happens again. This would explain everything. Only thing is I am not sure if an interrupt pending bit for a PIO Controller is only generated when PIO_ISR goes from 0 to 1, but I think this is the case from what I saw while debugging.

Now how can I prevent this error? I tried disabling interrupts, but the same error occurs. Only thing that seems to work is reading PIO_ISR directly before writing AIC_EOICR. But in doing this I can miss interrupts. I thought of writing some irq disabling and enabling code in the asm wrapper, but I am unsure what exactly I would have to write there.

Has anyone an idea which could fix this problem?

Thx!

The only thing that really comes to mind is to reduce the processing in your interrupt so that it is completed faster. Only do what is absolutely necessary in your interrupt and pass off the heavy data processing to a higher level function.

Hello, I'm new in AT91SAM7X-EK but would like to install an interrupt too.
If I use

and

the line AT91C_BASE_AIC->AIC_SVR[AT91C_ID_PIOA]=(unsigned int)ex_int_handler; makes an Int-output and then remains in the Isr at booting and never comes back to main().

Could anyone correct/complete the code or post a link to a working gcc-sample please (or at least a good beginners-tutorial about ext-int in gcc) ?

Perhaps
http://www.at91.com/phpbb/viewtopic.php ... highlight=
can help out?
HTH,
Gerd

Hi Torben,
Have you found the ultimate solution for your problem ? I am having the same problem with yours when I have multiple pin interrupts on PIO B, one int seems clear the status of others.

Thanks,
Ed.

It's a three year old thread, probably too stale to illicit the original posters.

Read the register once, EOI, and service ALL the pending requests, or set events to service them later. Check it again immediately before you leave service. Keep interrupts short and sweet.

I'd have to go over the manual, but typically the requests from a given bank all OR together, and you might not have bit level granularity

This is how I do it
- Read the register (AIC_IVR)
- Service ALL the pending requests
- Write EOI

I'm not sure what you mean by "Check it again immediately before you leave service"

The problem is no matter how short the ISR is, there is still a chance the new INT comes in right before writing to EOI

Thanks for replying my post. Ed.

You can dismiss the AIC with an EOI *before* you actually service the interrupt so it will catch new ones, is it going to re-enter?

You can re-read the AIC_IVR, to observe if any pend during your service, and you can service them before leaving. This closes the window. As does checking the GPIO's, presuming they assert until dismissed, rather than pulse.

The trap you're falling into is EOI'ing interrupts that pend on the same latch while you perform service, and then wondering why you don't get an interrupt.