Can I Interrupt Someone with a Stupid Interrupt Question?

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a custom board that uses all UARTS, SPI and TWI. It's an ATUC3a0512 MCU development using AVR32 Studio.

I use the TWI only to interface with a real time clock chip. The USARTs handle serial communications to other devices and PC's.

I did my best to keep the interrupt functions short and sweet. However, I noticed if any interrupt happens during the TWI interrupt, the TWI interrupt locks up!

I tried to disable the USART during TWI scans by setting it's the idr bit. Once it set the ier bit after data had passed to the USART, the application locks up.

Question 1. Is there a maximum size for ISR's?

Question 2. Is it possible to change the size?

Question 3. Is a lower priority interrupt halted if triggered during a higher priority interrupt or delayed?

Best regards,
Mark O.

There is always a "simple" solution for a "complex" problem.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A1. Not that I am aware of.
A2. See A1.
A3. Delayed until the higher priority ISR is finished.

Post the minimal code that exhibits the problem. I'm sure this can be sorted out.

Letting the smoke out since 1978

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Answer 1: Yes: The capacity of your program space (Flash, RAM). :P Otherwise: No.

Return question 2: The size of what? The ISRs? “Size” in terms of “code size” or “execution time”?

Answer 3: Delayed, as digitalDan said, until all currently pending interrupts with higher priority are finished.

Question 4: What priorities are you using for your interrupts?

Reminder 5: Some interrupt flags must be cleared explicitly while some (like TXEMPTY) are cleared automatically if you do something “useful”. Are you clearing them correctly? If not, your application will re-enter an ISR forever, appearing locked up.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

catweax wrote:

Return question 2: The size of what? The ISRs? “Size” in terms of “code size” or “execution time”?

Question 4: What priorities are you using for your interrupts?

Reminder 5: Some interrupt flags must be cleared explicitly while some (like TXEMPTY) are cleared automatically if you do something “useful”. Are you clearing them correctly? If not, your application will re-enter an ISR forever, appearing locked up.

Thanks for the reply catweax.
Question 2: size is in code size. My last project we had to declare the room in assembly needed for the IRS function code.

Question 4: I am playing with priorities AVR32_INTC_INT0 - AVR32_INTC_INT3. From what I have read this is where the priorities are set? However, the documentation says there are 32 levels of priority?

Reminder 5: I am not explicitly clearing any flags. At this point I am using the ISR for the TWI using the AVR32 driver twi.c file. On the USART, I am only using the "USART->ier = AVR32_USART_IER_RXRDY_MASK;" to handle the receive data.

Note1: When I eliminated all IRS and just left the TWI, the program ran stable! I also changed the pull up resistors from 1K to 4.7K as found on another thread. I now believe the issues reside with the USART interrupts causing havoc somehow.

Best regards,
Mark O.

There is always a "simple" solution for a "complex" problem.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

2: Not necessary if you use the ASF.

4: I only know of those four priority levels. Where in the documentation does it say something about 32? Actually I was asking about which priorities you use for which ISRs, though.

5: I haven’t used TWI yet, so I wasn’t sure about that possibility. For the timers you must read the status register to clear the interrupt flag, for example.

The USART interrupts “causing havoc somehow” is rather unspecific...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello slowpokee,

A rule of thumb with embedded systems (an almost any software I think) is to keep interrupts as short as possible. So, set a flag inside the interrupt, or grab the data, or whatever, and do the time consuming processing outside interrupt context.

The AVR32 UC3 has 4 interrupt priorities (from 0 to 3), not 32!

I have some experience with the TWI module, and one of the problems that I have encountered is that since the TWI driver routines are interrupt driven, if the TWI speed is set too high (I usually keep it under 200KHz), sometimes the twi receive interrupt could miss one of the received bytes (because there was a TWI interrupt pending and another one came in before the first was one has handled). If the TWI Rx interrupt misses one byte, the TWI module will hang.

Try lowering the twi speed, increasing its priority level and reducing the size of the other interrupt handlers.

Daniel Campora http://www.wipy.io

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danicampora wrote:
Hello slowpokee,

A rule of thumb with embedded systems (an almost any software I think) is to keep interrupts as short as possible. So, set a flag inside the interrupt, or grab the data, or whatever, and do the time consuming processing outside interrupt context.

The AVR32 UC3 has 4 interrupt priorities (from 0 to 3), not 32!

I have some experience with the TWI module, and one of the problems that I have encountered is that since the TWI driver routines are interrupt driven, if the TWI speed is set too high (I usually keep it under 200KHz), sometimes the twi receive interrupt could miss one of the received bytes (because there was a TWI interrupt pending and another one came in before the first was one has handled). If the TWI Rx interrupt misses one byte, the TWI module will hang.

Try lowering the twi speed, increasing its priority level and reducing the size of the other interrupt handlers.

Thanks for the response danicampora. Your issues with the TWI makes sense. I believe the previous 1K pull up resistors were also impeding the signal from the slave chip and hanging the interrupt. I added 4.7K resistors and will slow down the speed.

I will moved most of the code inside the USART interrupt to the main while loop and cross my fingers.

I tried to implement the Free RTOS earlier and unfortunately ran out of memory. Tried to push the heap to external SRAM. But that's another thread and headache!

There is always a "simple" solution for a "complex" problem.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the input catweax. I believe the 32 number came from the FreeRTOS which I scrapped for now. I am clearing the status registers in the timer interrupts. It is done at the end of the function.
The USART interrupt havoc issue is most likely caused from the not so efficient functions. One of the issues is the TWI interrupt locking up when data is sent to the USART.

There is always a "simple" solution for a "complex" problem.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks everyone for all the great advise! I was able to stabilize the application by doing the following: Increasing the TWI pull up resistor from 1K to 4.7K, setting the TWI interrupt priority to level 4, setting the timer IRQ to level 3 with the clearing bit at the end of the function, setting all external driven IRQ's priority to level 1 and setting flags to process the "long" functions in the main while loop.
He-Ha!!!!

There is always a "simple" solution for a "complex" problem.