DRA829V: Interrupt priority Mask Implementation

Hi Jian,

We didn't find any useful information regarding interrupt priority masking in the referred sections. 


Regards,
Arslan

Hi Jian,

We are looking for a global priority masking register, for all the interrupts covered by VIM. I hope this clarifies this question a bit more. If you could point us to exact register name then it will be very helpful.

Much appreciated!
Rizwan

Hi Vineet,
thanks for the update.

Here is a scenario we have to handle, please share your thoughts about it:

• From task level (no active interrupt) allow only interrupts of priority more than 'x'

From your comment what I have understood is that we will have to disable all the IRQ channels which havepriority same or lower than 'x', and enable all such channels with priority greater than 'x'. This would be achieved by manipulating ENABLE_SET and ENABLE_CLR register bits for the required channels.

This will put a lot of software overhead as this scenario may occur repeatedly as 'x' will take different values during runtime.

Please advise on an efficient workaround.

thanks,
Rizwan

Hi Vineet,

This is a very critical topic for us. I will appreciate if you could update us about my previous comment.

thanks,
Rizwan

Hi Rizwan,

Sorry for the delay.

Unfortunately I don't see an easy way around this.

A possible workaround would be to read a memory location in the beginning of every ISR and do an early abort if it's lower than the stored value. This won't disable the interrupt but CPU would spend a fraction of the time instead.

Regards

Vineet

Hi Vineet,

If I understood correctly, you mean to keep a variable with required priority level in it. Upon interrupt first we do a comparison to see if we should proceed or not.

Since the interrupt source is not cleared, the interrupts will keep on coming, we will need to disable all such undesirable interrupt channels and enable other desirable channels whenever we plan to change this software based priority level. This will cause a big overhead.

Rizwan

Hi Rizwan,

Early exit does not mean don't clear the interrupt, it just means skipping other parts of ISR (whatever it may be)

This assumes that you are getting interrupts periodically and don't have an error event which generates interrupts continuously. Those have to be disabled I guess.

Regards

Vineet

Hi Vineet,

For example, if a peripheral generates the interrupt which is of lower priority than what is in our software priority mask. What steps will be executed before returning back to the currently executing task?

Let's say that this peripheral is a CAN module, and it generates an interrupt on every CAN event which means that it will be interrupting repeatedly or periodically.
We will have to disable this interrupt and enable it when we are changing the software priority mask to a lower value.

Please let me know if my understanding is correct.

thanks,
Rizwan

Hi Rizwan,

Normally you'd take the CAN interrupt and use the callback function to copy CAN data, right ? But for the special case you will just clear the interrupt without calling the callback. That's the workaround I suggested.

It will not stop periodic interrupts from CAN but allow you to get back faster.

If it doesn't serve your purpose then yes, you will have to disable the CAN interrupt altogether. But doing that for all interrupts is expensive every time the software priority mask changes, as you rightly pointed out.

I hope that answers your question.

Regards

Vineet