Electronic – Why aren’t the interrupts nested in an ATSAM controller

cortex-m0interrupts

The interrupt controller of an ATSAMD21 (based on a Cortex-M0+) is called NVIC (Nested Vector Interrupt controller), so I was hoping it would be easy to nest interrupts.

The documentation doesn't mention how an interrupt can interrupt another interrupt. Actually, it doesn't say much about the interrupts, as they don't even have their registers listed, being only mentioned under the chapter "Processor and Architecture", unlike other peripherals which have their own chapters.

Searching the headers and the debugger I found the following registers used by the interrupt controller:

enable register. Every one of 28 possible interrupts has a bit here.
pending register. same as above
priority register.

Setting an interrupt to be of higher priority than another one, still doesn't allow it to interrupt the lower priority one.

The application notes about interrupts don't mention any way of nesting interrupts, it is rather written that:

Inside an ISR, interrupts are disabled. Therefore don’t do anything
that requires an interrupt to be serviced.

EDIT : Thanks to pointing me to the ARM documentation, where it is stated that higher priority interrupts always preempt lower priority interrupts.
However, some experiments show that it either does not happen on my board, or it takes too long.

Experimental setup

The links to this question showed statements that interrupt nesting is not only possible, but actually the only option for Cortex-M0 processors. Still, my experiments show otherwise.

In a timer overflow interrupt, the first thing I do is to check the value of the timer, thereby getting the interrupt latency (+ the few clocks required to read the timer). I calculate the maximum of this latency over the period of at least one minute.

If I only have this timer running, I have times below 1.5 µs
If I start several SPI senders (SERCOM), all transmitting continuously (all they do in their transmit interrupt is to fetch the next byte), I measure 4.2 µs
If I put a deliberate time wasting code (a few floating point operations) into two of the SERCOM transmit interrupts, I measure 140 µs!
If I put the timer interrupt to priority 0 (the highest) and all SERCOMs to priority 3, I measure 70 µs! Half of the time that I measured when all the interrupts had the same priority. This also seems to show that the SERCOM interrupt was never interrupted by the timer interrupt.
If I double the floating point operations in the SERCOM interrupts, the worst case latency in the timer interrupt is almost 140 µs, which would indicate that they are not interrupted.
If I put an endless loop after the float operations, the time is still 140 µs, so the endless loop does get interrupted. (And it was not optimized away – if I set all interrupt priorities back to the same value, it gets stuck in the endless loop)

EDIT My mistake was that although I set the priorities to the SERCOM interrupts, I didn't set it to all of them. SERCOM interrupt priorities have to be set individually. Closing the question, as I think it deviated too much from its original concept to have this posted as an answer.

Best Answer

That's because the NVIC is not part of Atmel but instead it's a part of IP supplied by ARM. Therefore you will find all documentation regarding this part on the ARM website for your specific core https://developer.arm.com/docs/dui0662/latest/4-cortex-m0-peripherals/42-nested-vectored-interrupt-controller

Related Solutions

Electronic – Using multiple external interrupts in PIC

This is C pseudo-code to explain one idea. It uses and exclusive OR to work out which pins have changed and will call your different handlers within the one RBIE interrupt. Depending on how critical the application is you may want to check how the PIC handles situations such as a port changing while the interrupt is executing to make sure you won't miss any events.

int old_port_b;

void isr_handler()
{
    int new_port_b, changed_pins;
    new_port_b = read_port_b();
    changed_pins = new_port_b ^ old_port_b;
    if (changed_pins | 1)
        rb0_hander();
    if (changed_pins | 2)
        rb1_hander();
        // ... etc
    old_port_b = new_port_b;
}

int main()
{
    old_port_b = read_port_b();
    enable_interrupt();
}

Electronic – arduino – Using ADC interrupts and TIMER interrupts at the same time

One thing that I notice from your code is that you are acquiring the samples in free running mode with ADC clock at F_CPU/2. According to the Atmega 328P datasheet

In Free Running mode, a new conversion will be started immediately after the conversion com- pletes, while ADSC remains high.

and the conversion time for free running mode (on table 23-1, page 255) is specified as 13 ADC clock cycles. This means that your ADC ISR is firing every 26 clock cycles with your current prescaler settings. On top of that, your TIMER1_COMPA ISR is also fired so frequently (every 64 cycles) that your ISR might actually take longer to execute than the desired time. You basically use all your time acquiring data and/or in your timer ISR. An easy solution is to increase the count in OCR1A to, say, 5 and increase the prescaler of the ADC

ADCSRA |= (1 << ADPS1); // ADC prescaler 8, conversion time 4*26 MCU cycles
OCR1A = 5; // 5*64;

If you want to squeeze every last drop of performance out of the old 328 you should inspect the generated assembly for your interrupt routines, and figure out if you can do something to optimize them. Common performance hogs are, for example, frequent data fetches from SRAM, but if you're using gcc you might find all sorts if groovy stuff happening upon ISR entry.

Keep in mind that the human eye cannot detect insanely fast flickering (hence pwm driven leds work as they do, with no visible flicker). If the slower running rate looks visually unpleasant you can of course try to reduce the prescaler and OCR1A, but you should also consider dispensing the ISR's altogether and just run your led flashing code in the main loop and have just the ADC ISR acquire data to be processed. This might work better since every function call takes at minimum 8 cycles (might have been 6, memory is a bit fuzzy on this particular detail) PLUS all the stack PUSH'n an' POP'n, which depends on your variable usage. So you could go for something like:

while(1) {
   checkData();
   handleLeds();
}

and have both functions be inlined.

Best Answer

Related Solutions

Electronic – Using multiple external interrupts in PIC

Electronic – arduino – Using ADC interrupts and TIMER interrupts at the same time

Related Topic