S32DS PA SDK interrupt management gotcha

[dan_teodorescu]

Hello,

The function INT_SYS_EnableIRQ() indifferently sets the interrupt priority to a value of FEATURE_INTERRUPT_DEFAULT_PRIO for a specific interrupt source. This function is called by other drivers in the SDK, and the change to the interrupt priority is not obvious to the caller of those other drivers. This will likely result in applications having unintended interrupt priority levels. 

A better solution is to deprecate the call to any interrupt manager (INT_SYS_*()) functions from the other sdk drivers such that only user code makes changes to the INTC registers. Furthermore, INT_SYS_EnableIRQ() should only ensure that the requesting core will be notified on the interrupt request, but it should not change the interrupt priority level. The other drivers should control interrupt requests by enabling or disabling their respective module's interrupt enable configuration registers. I.e. interrupts requests are controlled at the source rather than at the INTC module.

Dynamic interrupt priority adds unnecessary complexity and possibly  bugs in the design. The proposed interrupt management model described above would support a static interrupt priority assignment loaded once by the application at startup.

Thank you,

Dan

[ovidiualexandru]

Hi Dan,

Greetings from the S32 SDK Team!

Your proposal has been discussed internally within our team. We have agreed that the current interrupt model is not the best as it could be, so we are implementing some changes, based on your feedback:

 - the priority level will be settable even though the interrupt is not active

 - INT_SYS_EnableIRQ() will not change an already set priority

and, based on other past experiences:

 - INT_SYS_EnableIRQ() will enable the interrupt only on the current core, avoiding spurious interrupts on the other cores

The changes are in the final stages of testing, and should be available with the next release, coming soon.

Your proposal:

deprecate the call to any interrupt manager (INT_SYS_*()) functions from the other sdk drivers such that only user code makes changes to the INTC registers

Is not as simple as it might seem. Though it is a sound proposal, it would automatically require that all applications explicitly enable the interrupts required by the drivers that are used.

This impacts both the ease-of-use aspect, as now there are extra steps involved when adding a new driver to the project, and also portability of the project. Say you want to move your great project from one platform to another. In some cases, the interrupt names (*_IRQn), are not the same, so you have to figure out which names to use for the new project. This is time that we don't want our users to waste! The drivers can take care of this.

There are plenty of cases where different interrupt priorities are a necessity. We don't want to restrict the possibilities for our users. But also we strive to achieve a balance between configurability and usability. Hopefully with the changes we are adding, the mix is just right.

Best regards,

The S32 SDK Team

[dan_teodorescu]

Hello,

Thank you for the update. I am glad to hear of the upcoming changes.

Can you explain the strategy for how SDK drivers will internally enable and disable interrupts? In particular could the SDK drivers temporarily disable a particular interrupt, and subsequently re-enable it? If so how will the original interrupt priority be restored?

Thank you,

Dan

[ovidiualexandru]

Hi Dan,

You will be able to see the full details of the new implementation pretty soon.

To answer your question, the interrupt priorities are not modified when enabling/disabling interrupts via interrupt manager, unless these have the value 0. An interrupt with priority 0 is never executed (essentially disabled), so we set it to a default in INT_SYS_EnableIRQ. If the value is different than 0 (set by the user), we don't change it. We use this to our advantage, combined with the information about which core has the interrupt routed. A core that does not have the interrupt routed to it means that the interrupt is disabled.

The drivers approach to using the interrupt manager is unchanged. But now, the interrupts can have their priorities altered before enabling them. This should allow you to set priorities for any interrupt before calling the driver's Init() function, making sure that the interrupt is running with its desied priority at all times.

Best regards,

Ovidiu

[dan_teodorescu]

Hi Ovidiu,

This sounds like a very good implementation. I’m looking forward to the new SDK.

Thank you,

Dan