2018-02-20 12:33 AM
All of the STM32 devices have unimplemented interrupt numbers, for example on the STM32F767 I am currently using, the last used interrupt MDIOS_IRQn is interrupt number 109.
So is it possible to use the next one, number 110, as a user software interrupt? Obviously there is no peripheral device connected to this interrupt line so there is no danger of a spurious interrupt request, but what's stopping us from defining our own interrupt as
MYOWN_IRQn = 110
And then enabling it and disabling it with NVIC_EnableIRQ(), adding another entry to the interrupt vector table in startup_stm32f767xx.s and using it as a user-defined software interrupt?
2018-02-20 12:53 AM
ARM implemented the Supervisor Call (SVC) instruction for that very purpose.
2018-02-20 02:27 AM
>>
ARM implemented the Supervisor Call (SVC) instruction for that very purpose.
Yes, but still, the question is valid.
(Actually, I have another reason for doing this. I would like to install a 'dummy' interrupt that I can freely execute without any effect on any peripherals. Yes, I could hijack SVC for this but I don't want to abuse that feature.)
2018-02-20 03:31 AM
But how would you actually 'trigger' this interrupt ?
2018-02-20 03:34 AM
Likely bits not implemented in NVIC, best to just reuse existing slots you aren't actually using, ie CAN2 or TIM19
2018-02-20 03:47 AM
By setting the respective bit in NVIC_ISPRx, of course, maybe through CMSIS' NVIC_SetPendingIRQ().
However, it may well be that there's no hardware for these interrupts in NVIC.
JW
2018-02-20 04:01 AM
Yes, it will work. You can simply set the flag, assuming that the nvic is set up somewhere else. Some modifications to the start up file may be necessary.
The same works for implemented but unused interrupts.
And on other chips too.
2018-02-20 04:08 AM
waclawek.jan wrote:
it may well be that there's no hardware for these interrupts in NVIC.
Indeed - there's the catch!
Relying upon undocumented / unsupported features is never a Good Thing ...
2018-02-20 04:28 AM
Indeed, the vector table differs between sub variants, as the officially implemented peripherals differ.
Be prepared for surprising results.
There have been STM32s around for years with more Flash than documented, due to defect-related 'downgrading' in the factory functional tests.
2018-02-20 04:37 AM
AvaTar wrote:
There have been STM32s around for years with more Flash than documented, due to defect-related 'downgrading' in the factory functional tests.
Not just STM32 - that's a common industry practice
Car manufacturers, white goods manufacturers, et al, do similar things..