Priority order violation - Asserion fails Topic is solved

[fotis]

Assuming that's lwIp you're running, I have a vague recollection of a similar problem. In my case it was down to insufficient stack allocation for one of the tasks; a networking-related one IIRC.
(The Chibi plugin for Eclipse will show you stack usage)

Note that you can actually use the debugger to see the states of variables at any point in the execution stack, just by highlighting the relevant level - that can sometimes give clues.

I have checked the stack usage, and I am sure that is more than sufficient (several kb more than necessary). I have also checked my heap, the exceptions stack, the main system stack... everything. I was sure that this is a memory related issue, but as it seems my memory is OK.

The problem could be originated in another place, are you using any I-class API (those whose name ends with an "I") from thread context?

Giovanni

I have triple checked the code, and there are no calls to I-class functions. At all, i.e. neither in exception nor in thread context.

[fotis]

Regarding the I-Class functions (and generally the correct API usage), shouldn't the checks catch this?

I think I have all checks enabled.

[Giovanni]

The "state checker" does catch that kind of errors.

Do you have IRQs? are all IRQs into the valid priority range? priorities 0...2 are special and cannot call RTOS code from those.

Giovanni

[fotis]

Yes I do have interrupts.

My start-up code sets the priority for ALL interrupts to 5.
Then Chibios starts which sets:

Code: Select all

NVIC_SetPriorityGrouping(CORTEX_PRIGROUP_INIT);    //CORTEX_PRIGROUP_INIT = 2
NVIC_SetPriority(SVCall_IRQn, CORTEX_PRIORITY_SVCALL);    //CORTEX_PRIORITY_SVCALL = 1
NVIC_SetPriority(PendSV_IRQn, CORTEX_PRIORITY_PENDSV);    //CORTEX_PRIORITY_PENDSV = 2
NVIC_SetPriority(SysTick_IRQn, CORTEX_MAX_KERNEL_PRIORITY + 1);    //CORTEX_MAX_KERNEL_PRIORITY = 1, thus systick priority is 2.


I also have disabled CORTEX_SIMPLIFIED_PRIORITY.

[fotis]

I just realized that I make use of a specific I-class function. Within my SysTick handler.

Unlocking the system will cause a reschedule, so I don't think that this is the problem.

My handler:

Code: Select all

void SysTick_Handler()
{
   CH_IRQ_PROLOGUE();

   chSysLockFromISR();
   chSysTimerHandlerI();
   chSysUnlockFromISR();

   CH_IRQ_EPILOGUE();
}

[Giovanni]

Try to lower systick priority, right now it is equal to PendSV and that could be the problem.

Also inspect NVIC registers and verify that priorities are as you expect.

Giovanni

[fotis]

Unfortunatelly it seems that either the priority of SysTick is the issue.

I have set:
SVCall to 1
PendSV to 2
SysTick to 3
All other interrupts to 5

I just had one more occurrence of the problem.
Any other ideas on what to check?

[Giovanni]

You need to check into NVIC registers:

1) Priorities.
2) How priority grouping is set. You need to not have groups or priorities that should be at different levels would be in the same group.

Giovanni

[fotis]

Sorry, I was once again travelling abroad for business... Now I have some time for my project again.

I spent some time investigating about the interrupts. I added some debug prints in my chSysHalt handler, so I can get exactly all NVIC settings when the assertion fails.

As I see all settings are the intended ones, so no nasty code doing stuff behind my back.
All priorities are set only once, during initialization, before Chibios starts. No runtime changes. I think this simplifies things a lot.

The output of my prints is the following:

Code: Select all

Priority grouping: 2

Interrupt -14, priority: 0      // Non maskable interrupt.
Interrupt -13, priority: 0      // Unused.
Interrupt -12, priority: 0      // Memory management interrupt.
Interrupt -11, priority: 0      // Bus fault interrupt.
Interrupt -10, priority: 0      // Usage fault interrupt.
Interrupt -9, priority: 0      // Unused.
Interrupt -8, priority: 0      // Unused.
Interrupt -7, priority: 0      // Unused.
Interrupt -6, priority: 0      // Unused.
Interrupt -5, priority: 1      // SVCall interrupt.
Interrupt -4, priority: 0      // Debug monitor interrupt.
Interrupt -3, priority: 0      // Unused.
Interrupt -2, priority: 2      // PendSV interrupt.
Interrupt -1, priority: 3      // Systick interrupt.

Interrupt 0, priority: 5
Interrupt 1, priority: 5
Interrupt 2, priority: 5
Interrupt 3, priority: 5
Interrupt 4, priority: 5
Interrupt 5, priority: 5
Interrupt 6, priority: 5
Interrupt 7, priority: 5
Interrupt 8, priority: 5
Interrupt 9, priority: 5
Interrupt 10, priority: 5
Interrupt 11, priority: 5
Interrupt 12, priority: 5
Interrupt 13, priority: 5
Interrupt 14, priority: 5
Interrupt 15, priority: 5
Interrupt 16, priority: 5
Interrupt 17, priority: 5
Interrupt 18, priority: 5
Interrupt 19, priority: 5
Interrupt 20, priority: 5
Interrupt 21, priority: 5
Interrupt 22, priority: 5
Interrupt 23, priority: 5
Interrupt 24, priority: 5
Interrupt 25, priority: 5
Interrupt 26, priority: 5
Interrupt 27, priority: 5
Interrupt 28, priority: 5
Interrupt 29, priority: 5
Interrupt 30, priority: 5
Interrupt 31, priority: 5
Interrupt 32, priority: 5
Interrupt 33, priority: 5
Interrupt 34, priority: 5


It seems OK, to me.
The only unclear thing for me is the priority grouping. It is set to Chibios default, which the documentation states that disables all grouping (which is what I want).

[Giovanni]

Yes, priority grouping is disabled by default. It could be used but it would require reassigning priorities, I would not recommend it.

Which compiler are you using?

Giovanni