NVIC table

Question

Hi, 
 could you please tell where can I find a table showing all the NVIC interrupt vectors? 
 I searched in the nRF52840 datasheet but I did not find something relevant 
 Thank you

wpaul · Accepted Answer

Originally you mentioned the AVR processors and how they handled interrupts, but it looks like you edited that part out. There is a similarity in that both the Atmel AVR and ARM processors use the vectored interrupt model. The AVR model is a bit simpler though in that it doesn't have a dedicated interrupt controller block like the NVIC. 
 The ARM Cortex-M vector table starts at address 0x0 which is in the flash. Every 4 bytes contains the address of the interrupt handler for that vector. When the CPU gets an interrupt, it will branch to the address specified there. 
 Populating the slots at compile time is done with a little bit of linker magic. If you look at, say, modules/nrfx/mdk/gcc_startup_nrf52840.S, there's a table called __isr_vector which defines the vector table, and it has various slots filled with handler functions, such as GPIOTE_IRQHandler. If you look further down, you'll also see a definition for a simple function called Default_Handler that's just an infinite loop. Right below that are a bunch of aliases with names that match the handler functions specified in the __isr_vector table. You'll see they're prefixed by an "IRQ" macro which defines these alias using the .weak attribute. This is a hint to the linker that these are weak symbols. 
 What this does is tell the linker: "If someone provides another function with the same name that doesn't have the .weak attribute (i.e. a "strong" symbol), then put that function's address into the vector table, otherwise use the weakly defined one, which is just a do-nothing loop." 
 So effectively all you need to do to add an interrupt handler is to just create your own function with the right name and then link it in. The linker scripts will tell the linker to put the __isr_vector table at the start of your image and populate it correctly. This is less hassle than having to manually edit the gcc_startup_nrf52840.S file and insert your own ISR every time you want to make a new project (though you could do that if you really wanted to). 
 I'm pretty sure that if you use avr-gcc/avr-libc to write programs for the AVR chips, it does something very similar. 
 Nordic then wraps this up in some abstraction macros, which is why instead of using GPIOTE_IRQHandler you use nrfx_gpiote_irq_handler. This makes things a little confusing because if you want to set a breakpoint, you have to tell the debugger to use the actual symbol name GPIOTE_IRQHandler, not the macro name nrfx_gpiote_irq_handler. 
 Note that what I've just described is the ARM interrupt handling mechanism. You complicated things a little by asking specifically about interrupts for GPIO pin changes. The ARM CPU doesn't really define how that works: lots of vendors use ARM cores (Nordic, NXP, ST Micro, etc...) but they add their own peripheral stack. (By contrast, Atmel is the only one that makes AVR processors and they also design the peripherals.) 
 In the case of the nRF52840, Nordic has two components: the GPIO component, which lets you configure and control pins, and the GPIOTE component, which is responsible for generating interrupts when the input state of one of the GPIO pins changes. 
 One thing to be aware of is that while the nRF52840 has 48 pins which can be used as GPIOs, the GPIOTE component has only 8 channels for signalling events. That means that you can only sense interrupts from at most 8 pins at any given time. It works sort of like this: 
 - You decide you want to be able to sense input changes on pin P0.24 
 - You configure pin P0.24 as an input, configure pullups, etc... using the GPIO module 
 - You choose one of the GPIOTE channels, say channel 0 
 - You program GPIOTE channel 0 to respond to pin P0.24, and select what events you want to respond to (lo to hi, hi to low, both) 
 Now when the input state of P0.24 changes, the GPIOTE interrupt will fire. The interrupt handler must then check which of the 8 channels signaled a state change (could be more than one if you set up multiple channels), acknowledge the interrupt and act accordingly. 
 In the Nordic SDK this is abstracted in their driver and library code. What's important to note is that the in_pin_handler() function is not the actual interrupt entry point. The actual entry point is nrfx_gpiote_irq_handler/GPIOTE_IRQHandler, and that function will eventually call back to your in_pin_handler() function. 
 It's only the GPIO support that's set up like this. For other peripherals, like the UART, SPI controller, I2C controller, etc..., each peripheral has an IRQ directly associated with it. When you use one of the SDK drivers/libraries for a given peripheral, it will provide its own interrupt handler. 
 -Bill

NVIC table

Top Replies