Which Cortex-M3 interrupts can I use for general purpose work?

Question

I'd have some code that needs to be run as the result of a particular interrupt going off.

I don't want to execute it in the context of the interrupt itself but I also don't want it to execute in thread mode.

I would like to run it at a priority that's lower than the high level interrupt that precipitated its running but also a priority that higher than thread level (and some other interrupts as well).

I think I need to use one of the other interrupt handlers.

Which ones are the best to use and what the best way to invoke them?

At the moment I'm planning on just using the interrupt handlers for some peripherals that I'm not using and invoking them by setting bits directly through the NVIC but I was hoping there's a better, more official way.

Thanks,

Answer 1

ARM Cortex supports a very special kind of exception called PendSV. It seems that you could use this exception exactly to do your work. Virtually all preemptive RTOSes for ARM Cortex use PendSV to implement the context switch.

To make it work, you need to prioritize PendSV low (write 0xFF to the PRI_14 register in the NVIC). You should also prioritize all IRQs above the PendSV (write lower numbers in the respective priority registers in the NVIC). When you are ready to process the whole message, trigger the PendSV from the high-priority ISR:

*((uint32_t volatile *)0xE000ED04) = 0x10000000; // trigger PendSV

The ARM Cortex CPU will then finish your ISR and all other ISRs that possibly were preempted by it, and eventually it will tail-chain to the PendSV exception. This is where your code for parsing the message should be.

Please note that PendSV could be preempted by other ISRs. This is all fine, but you need to obviously remember to protect all shared resources by a critical section of code (briefly disabling and enabling interrupts). In ARM Cortex, you disable interrupts by executing __asm("cpsid i") and you enable interrupts by __asm("cpsie i"). (Most C compilers provide built-in intrinsic functions or macros for this purpose.)

Answer 2

Are you using an RTOS? Generally this type of thing would be handled by having a high priority thread that gets signaled to do some work by the interrupt.

If you're not using an RTOS, you only have a few tasks, and the work being kicked off by the interrupt isn't too resource intensive, it might be simplest having your high priority work done in the context of the interrupt handler. If those conditions don't hold, then implementing what you're talking about would be the start of a basic multitasking OS itself. That can be an interesting project in its own right, but if you're looking to just get work done, you might want to consider a simple RTOS.

Since you mentioned some specifics about the work you're doing, here's an overview of how I've handled a similar problem in the past:

For handling received data over a UART one method that I've used when dealing with a simpler system that doesn't have full support for tasking (ie., the tasks are round-robined i na simple while loop) is to have a shared queue for data that's received from the UART. When a UART interrupt fires, the data is read from the UART's RDR (Receive Data Register) and placed in the queue. The trick to deal with this in such a way that the queue pointers aren't corrupted is to carefully make the queue pointers volatile, and make certain that only the interrupt handler modifies the tail pointer and that only the 'foreground' task that's reading data off the queue modified the head pointer. A high-level overview:

• producer (the UART interrupt handler):

  1. read queue.head and queue.tail into locals;
  2. increment the local tail pointer (not the actual queue.tail pointer). Wrap it to the start of the queue buffer if you've incremented past the end of the queue's buffer.
  3. compare local.tail and local.head - if they're equal, the queue is full, and you'll have to do whatever error handing is appropriate.
  4. otherwise you can write the new data to where local.tail points
  5. only now can you set queue.tail == local.tail
  6. return from the interrupt (or handle other UART related tasks, if appropriate, like reading from a transmit queue)

• consumer (the foreground 'task')

  1. read queue.head and queue.tail into locals;
  2. if local.head == local.tail the queue is empty; return to let the next task do some work
  3. read the byte pointed to by local.head
  4. increment local.head and wrap it if necessary;
  5. set queue.head = local.head
  6. goto step 1

Make sure that queue.head and queue.tail are volatile (or write these bits in assembly) to make sure there are no sequencing issues.

Now just make sure that your UART received data queue is large enough that it'll hold all the bytes that could be received before the foreground task gets a chance to run. The foreground task needs to pull the data off the queue into it's own buffers to build up the messages to give to the 'message processor' task.