September 29, 2023

Raspberry Pi Pico - Interrupts and exceptions

I am coming from a background in Cortex-A, and am pleasantly surprise that Cortex-M is neat and simple. There is no ugly "coprocessor interface" to access system registers.

You have msr xxx,reg (move to special register) and mrs reg,xxx (move from special register). Here "xxx" is the special register (such as PRIMASK) and the few special registers that there are all have nice distinct names.

PRIMASK

So, what about PRIMASK? How many priority levels are supported? As it turns out this is a single bit (in a 32 bit register)

Using cpsid and cpsie would seem to be clean and simple, although you could use msr/mrs to set PRIMASK with equal effect. However using msr/mrs would require you to use a register and you would end up using at least 2 instructions where cpsid/cpsie would use only one. Conclusion is to use msr/mrs only if you really need to do something different depending on what is in a register.

I use the following macros: 

#define INT_enable()           asm volatile ( "cpsie i" : : : "memory")
#define INT_disable()          asm volatile ( "cpsid i" : : : "memory")
Some code makes statements like "this sets the I-bit in the CPSR in order to disable interrupts." As far as I know the Cortex-M doesn't have a CPSR, so this statement may well be true on other architectures, but it is misleading here. The Cortex-M has PRIMASK as an independent register all its own.

CMSIS

I trip over this now and then and it seems to be a set of software conventions set up by someone. The someone seems to be ARM: It is all supposed to be on Github, and apparently is as different versions and flavors. While I understand and even commend such a thing, it is exactly what I want to avoid in order to learn about hardware details.

Interrupts versus Exceptions -- and the vectors

So, if you set the PRIMASK bit, you "mask" or block or disable interrupts. Very good, but what do you not mask? As a key example, what about systick? Hard to find out reading the documentation. Some simple experimentation shows that it does. This is good, but not what I was predicting.

Sometimes documentation just doesn't explain things you wish it did. I understand why this happens. If the documentation writers understand what they are writing about (and we hope that they do), it is easy for them to forget what someone new to all of this does and doesn't know. In truth, dealing with this very issue is what separates the men from the boys when it comes to writing good documentation. In the meanwhile, we have to resort to experiments many times to clarify issues that good documentation ought to clarify.

What else might be masked? NMI obviously not, just by name. Hard fault? I doubt it. svcall? Maybe.

Have any comments? Questions? Drop me a line!

Tom's electronics pages / tom@mmto.org