How do I setup EXTI[15:10] interrupts without enabling them until required?

[Mike xx]

If I tick the enable box in STM32CUBEMX the interrupt is enabled when MX_GPIO_Init() is executed. Since this is prior to the initialisation of FreeRTOS queues etc this turns into a disastrous mess.

If I leave the box unticked then everything assoociated with this interrupt must be written manually.

It's a shame that the interrupt can't be setup in the MX and then manually enabled when the appropriate FreeRTOS task becomes active.

[waclawek.jan]

> If I leave the box unticked then everything assoociated with this interrupt must be written manually.

And why would that be a problem? It's a write to two or three registers, and then enabling the interrupt in NVIC. Hardly a challenge.

Cube/CubeMX inevitably caters only for a limited subset of the virtually infinite modes of usage of the peripherals. There's just so many things you can control by clicking. I'm sure ST is willing to provide you a dedicated clicking interface for whatever functionality you desire, if you present a significant buying power (as expressed in $M+).

JW

[Mike xx]

Yes I appreciate it can't be the singing and dancing solution for everyone all the time. But when FreeRTOS is used, where queues are typically filled from interrupts it becomes a certain failure for anyone using FreeRTOS.

[Pavel A.]

No, it is not a shame, you just need to know the trick.

Insert the following line before the cube generated code that configures NVIC interrupts:

__set_BASEPRI(configMAX_SYSCALL_INTERRUPT_PRIORITY);

This will disable all interrupts that should not occur before FreeRTOS scheduler starts.

When it starts and any thread runs, BASEPRI will automatically return to 0 and these interrupts will be unmasked.

And the life is good again =)

Note: assuming that priority of HAL timer interrupt is higher than SYSCALL_INTERRUPT_PRIORITY. The HAL tick is used to detect timeouts during initialization of many HAL drivers so it should normally work as soon as the HAL starts it.

-- pa

[Mike xx]

I can see the significance of your note. The current priority set by the FreeRTOS middleware is now 15. Until the latest version of MX it was 0, so unmaskable. I have no idea why the change but of course it does mean that HAL_Delay no longer works.