EEbeat

Today I’d like to discuss interrupt response again relative to the Renesas RX microcontroller (MCU) architecture. We’ll add an external interrupt into the mix and prepare for a later examination of how to minimize the exit time for interrupts.

 Let’s first take a look at the type of response that you can get from nested interrupts. We’ll rely on the scenario that I described in the first post that I did on measuring interrupt response time. The test described measuring the interrupt response when an integrated timer was used to generate an interrupt upon overflow. The interrupt service routine (ISR) then read the value of the timer, and that value was the measure of the interrupt response time because the timer resets itself to zero upon overflow in addition to generating an interrupt.

 Application engineers changed the test code bringing an external interrupt into the equation. The new test relies on the timer ISR to drive a signal on the RX610 prototype board low that in turn triggers an external interrupt on IRQ14. In the test code, IRQ14 was configured as a falling-edge interrupt with a priority that’s higher than that of the timer interrupt. So the external interrupt causes the RX to stop the timer ISR and service IRQ14.

 The IRQ14 ISR does little more than drive the triggering signal back to a high state. The application engineers used a scope to measure the time the triggering signal was low, to measure the response to the external IRQ14 interrupt. And remember that servicing that interrupt required that the RX first exit the timer ISR.

 The external interrupt response was measured to be 320 nsecs or 32 CPU clock cycles. Of that 32 cycles, 6 cycles were spent in the IRQ14 ISR. So the time it took to exit the timer ISR and dispatch the first instruction in the IRQ14 ISR is 26 CPU cycles.

 We can take a brief look at what happened during the 26 CPU cycles. The RX must POP the registers used by the timer ISR and restore the program counter (PC) and processor status word (PSW). The interrupt control unit (ICU) must process the new external interrupt, load a new interrupt vector from memory, and transfer control to the new address.

 I’ve described the nested interrupt scenario for a couple of reasons. First the 26-cycle response is really good for servicing a nested interrupt. Moreover it could be made faster using the same techniques that I described in the post on the fast interrupt function and dedicated interrupt registers. If IRQ14 was deemed the most critical interrupt in the system, the backup PC and PSW could have shaved a couple of clock ticks off the interrupt response time, and dedicating registers to the ISR could save additional cycles in the IRQ14 ISR.

 I also described this example to set the stage for another post on how the fast interrupt function accelerates the exit from an ISR – coming soon.

This blog post was originally published on the Renesas Rulz Doctor Micro blog.