Problem using __BASEPRICONFIG()

[philippe239955_st]

Posted on November 12, 2009 at 10:37

Problem using __BASEPRICONFIG()

[clive2]

Posted on May 17, 2011 at 13:29

Doesn't the NVIC explicitly prohibit this kind of activity to prevent interrupt re-entrant behaviour, lower priority interrupts won't get carried out until the current one exits.

Have you considered using a task based RTOS? The method you want to use seems problematic, you should really just service hardware needs in the interrupts (or at least things you can do immediately without blocking), and push processing into worker tasks/threads. -Clive

[philippe239955_st]

Posted on May 17, 2011 at 13:29

Hi,

In my application in an interrupt routine that has high priority, on particular cases, I need to reduce it to the lowest level in order to have all other (lower level) interrupts to preempt it. In other terms, I need to remain in this interrupt and all other lower level interrupts should be able to run without leaving this higher level interrupt. What I did is I inserted in this high level interrupt: __BASEPRICONFIG(x) with x being the lowest interrupt value priority (15 in my case)... But this does not work, all lower level interrupts won't preempt it. If any body has a solution, thanks! Phil

[akaiser9]

Posted on May 17, 2011 at 13:29

Split your interrupt handler in two parts, one with high priority and a second one with low priority. Then add a software interrupt trigger to the end of the first.

[philippe239955_st]

Posted on May 17, 2011 at 13:29

I am aware of this particularity... In fact this is a ''unique'' behaviour in the software and the task that may cause interrupt re-entry is killed just before this.

Other low running interrupts are USART comm and Power supply regulation, these I need to run in ''background'' until the user decides to reset the software... and this is the only way that I plan in getting out of this ''particular'' error case. In more detail this portion of code is an error macro (assert param error)that I plan in calling (on error) not only in the sequential part of the program, but also in an interrupt instead of doing countless function (or interrupt) error returns. Well if NVIC prevents this, then I got my answer unless there is a way in ''cheating'' ;) ... well thanks anyway. Phil