STM32 unimplemented interrupts

[FLast.17.70]

Posted on February 20, 2018 at 09:33

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?

[AvaTar]

Posted on February 20, 2018 at 09:53

ARM implemented the Supervisor Call (SVC) instruction for that very purpose.

[FLast.17.70]

Posted on February 20, 2018 at 11:27

>> 

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.)

[Andrew Neil]

Posted on February 20, 2018 at 11:31

But how would you actually 'trigger' this interrupt ?

[waclawek.jan]

Posted on February 20, 2018 at 11:47

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

[Tesla DeLorean]

Posted on February 20, 2018 at 12:34

Likely bits not implemented in NVIC, best to just reuse existing slots you aren't actually using, ie CAN2 or TIM19 

[henry.dick]

Posted on February 20, 2018 at 13:01

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.

[FLast.17.70]

Posted on February 20, 2018 at 15:12

Well, I've tried it and it doesn't work. 

It appears that for any interrupt not defined by ST for the particular device you are using, enabling the corresponding interrupt has no effect and setting the interrupt pending has no effect either. The NVIC seems to mask off any attempts to set the nonexisting bits in the NVIC->ISER[] register.

Thus for example on the STM32F405, when I tried to set NVIC->ISER[2] to 0xFFFFFFFF (enable all interrupt numbers from 64 to 95), the value of 

NVIC->ISER[2] changes to 0x0003FFFF (interrupt numbers 64 to 81 get enabled but the others won't). This is in line with the fact that for this device, the last interrupt is defined as number 81 (FPU_IRQn). 

I assume there is some gates implemented in the actual chip that hard wire the unused NVIC->ISER bits to zero.

Well, anyway, you always learn something...

[henry.dick]

Posted on February 20, 2018 at 15:39

Did you also change the start up file? By default they point you to 0.

The implemented interrupt numbers are not continuous. So gating specific bits would work - they would have to gate specific interrupt numbers. 

[FLast.17.70]

Posted on February 20, 2018 at 17:08

>> 

Did you also change the start up file?

Yes, I did change the startup file and added my interrupt. It's not that. 

There is a single line in the 'Definitive Guide to the ARM Cortex-M3 and M4 Processors' book (section 7.8.2) where it details the NVIC->ISER register(s): 'Only the enable bits for interrupts that exist are implemented'. 

So no, it can't be done unless you drill into the silicon and hook up some more gates. But I haven't got a suitable drill for that, so that's the end of the story, I'm afraid.

[henry.dick]

Posted on February 21, 2018 at 01:57

I did some digging.

for unimplemented peripherals: I can still set the NVIC interrupt enable bits; I can route clock to the peripheral, but I cannot set the interrupt flag -> thus unable to trigger the interrupt: reading back memory locations associated with un-implemented peripheral gives all 0.

so I was wrong.