One thing I didnt mention earlier was that some cortex-M processors do have a VTOR register which can be used to relocate the vector table. The register has some “odd” alignment restrictions but those are not all that tough to deal with. This would be one way to deal with the bootloader issue but not all cortex-M processors have a VTOR.
I guess in the end it will be up to folks when they create their BSP to decide what they want. It shouldnt be too difficult to modify the code/linker scripts to accommodate both approaches. > On Jul 27, 2016, at 7:43 AM, Kevin Townsend <[email protected]> wrote: > > Hi Will, > > That's a good point. I've usually worked with very simple boot loaders in > the past. One of my biggest problems with the SD architecture (and > motivation for moving to mynewt and nimble) was the lack of strict timing > and direct interrupt control at the app level due to the interrupt handling > in the SD. > > But one or two clear examples of how to register your interrupt handler > should probably be clearly documented with the current approach then since > it differs from what most customers are used to(?) with CMSIS and most > vendor supplied example code. > > I don't have strong feelings either way myself though and the bootloader > argument is valid if you want to handle systick interrupts in both chunks > of code for example or radio and SPI events in an advanced bootloader. > > K. > > Le mercredi 27 juillet 2016, will sanfilippo <[email protected]> a écrit : > >> 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] >> <javascript:;>> 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 >> >>
