So how does a bootloader that uses interrupts and an application that uses the same interrupt work? If you have interrupt vectors in .text, only one “application” can own that interrupt vector. Of course, the interrupt vector in . text can look up a function pointer to call, but in that case you might as well just register the interrupt vector.
> On Jul 26, 2016, at 7:45 PM, Kevin Townsend <[email protected]> wrote: > > >> Bonsoir, > Bilingual, impressive! :P >> I’m OK with NVIC_SetVector(), and indeed, the driver that uses Nordic’s >> function can call that in the driver init function — however, I think it’s >> worth understanding why we want this located in RAM. It seems reasonable to >> me to fix the interrupt vectors in .text and avoid the NVIC_SetVector() call >> — it seems like we’re spending a bunch of RAM on something that will never >> change dynamically. >> >> Thoughts? > Personally, I can't remember the last time I had the interrupt vectors > anywhere except fixed in .text. I suspect 99% of the people working with ARM > Cortex devices are also familiar with and probably are sort of expecting the > typical 'weak' approach pushed by most CMSIS based vendor startup code. That > said ... I certainly don't feel strongly about this either way, but you > probably are losing a small chunk of SRAM for something 0.1% of users might > actually make meaningful use of. > > Kevin
