... and I believe in most similar chips. There is a "fan-in" from various sources of interrupts in one peripheral (with individual enable bits) into a single input into the interrupt controller; and there are around two dozens of such inputs with an enable bit each; and then of course the "global" interrupt enable (whatever it is called) in the core itself.

This reveals one more weakness of this (and I believe others too) ARM-based "microcontrollers" (SoCs): there is only one interrupt vector for a peripheral, which is shared for all kinds of interrupt that peripheral can generate. I remember from the "kitchen sink" thread a couple of years ago that quite a couple of people "requested" a separate interrupt for UART Rx and Tx in the '51. So, for those moving to ARMs, this is a bad news: upon each interrupt, one has to find out what was its particular source, if there are more than one enabled for that particular interrupt vector (i.e. peripheral).

There is one more unfortunate consequence of this architecture: there is no automatic "source" interrupt flag clear upon entering the interrupt service routine. So, the required procedure is to 1. find all the sources which triggered this interrupt; 2. clear their flags; 3. do the work itself.

So, at the end of the day, interrupt handling on ARMs is much clumsier than we were used to from real microcontrollers. Knowing that they are not microcontrollers I am not surprised nor shocked, just disappointed.

JW