Priority order violation - Asserion fails

Report here problems in any of ChibiOS components. This forum is NOT for support.
fotis
Posts: 24
Joined: Mon Apr 04, 2016 7:04 pm
Has thanked: 1 time

Re: Priority order violation - Asserion fails

Postby fotis » Tue Sep 11, 2018 8:35 pm

No, I mean that according to ARM priority grouping must be set to 0 to be disabled, but Chibios sets it to 2, which I hope is equivalent.

I am using gcc version 6.3.1 20170215.

User avatar
Giovanni
Site Admin
Posts: 11152
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 391 times
Been thanked: 322 times
Contact:

Re: Priority order violation - Asserion fails

Postby Giovanni » Wed Sep 12, 2018 1:20 pm

Try setting CORTEX_SIMPLIFIED_PRIORITY=1, does this hide the problem?

Giovanni

fotis
Posts: 24
Joined: Mon Apr 04, 2016 7:04 pm
Has thanked: 1 time

Re: Priority order violation - Asserion fails

Postby fotis » Wed Sep 12, 2018 7:29 pm

This is a good idea. I am starting testing now, and I will let you know.

fotis
Posts: 24
Joined: Mon Apr 04, 2016 7:04 pm
Has thanked: 1 time

Re: Priority order violation - Asserion fails

Postby fotis » Wed Sep 12, 2018 8:27 pm

Unfortunately the issue persists.

I set CORTEX_SIMPLIFIED_PRIORITY to TRUE and the issue is still reproducible.

This is the output of my priorities settings, in this configuration:

Code: Select all

Priority grouping: 2
Interrupt -14, priority: 0
Interrupt -13, priority: 0
Interrupt -12, priority: 0
Interrupt -11, priority: 0
Interrupt -10, priority: 0
Interrupt -9, priority: 0
Interrupt -8, priority: 0
Interrupt -7, priority: 0
Interrupt -6, priority: 0
Interrupt -5, priority: 0
Interrupt -4, priority: 0
Interrupt -3, priority: 0
Interrupt -2, priority: 0
Interrupt -1, priority: 1
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

User avatar
Giovanni
Site Admin
Posts: 11152
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 391 times
Been thanked: 322 times
Contact:

Re: Priority order violation - Asserion fails

Postby Giovanni » Thu Sep 13, 2018 8:00 am

Hi,

Then it is not related to priorities, you could have an I-class function called in thread context and not followed by an explicit reschedule.

This could be a problem in the lwIP adaption layer looking at your stack trace, it is possible something similar has already been reported.

Moving this topic in "bug reports".

Giovanni

fotis
Posts: 24
Joined: Mon Apr 04, 2016 7:04 pm
Has thanked: 1 time

Re: Priority order violation - Asserion fails

Postby fotis » Thu Sep 13, 2018 6:15 pm

I don't believe this is LWIP related.
I have developed my own layer between the LWIP (or whatever TCP/IP stack), and Chibios (or any other RTOS). In my application LWIP is running only within a specific thread. I also have set LWIP to NO_SYS=1.

Thus LWIP is completely unaware of the RTOS, and does not make any Chibios call at all. I checked this again now.

I also did an extensive check to my whole source code. Both using the Eclipse's tools, and also tried again with the ack tool.

I am pretty sure that there is only 1 call to an I-class function, throughout my whole source code: chSysTimerHandlerI(). This is called within the Systick handler, of course, and thus it runs in interrupt mode. According to the documentation a reschedule is not required, correct?

User avatar
Giovanni
Site Admin
Posts: 11152
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 391 times
Been thanked: 322 times
Contact:

Re: Priority order violation - Asserion fails

Postby Giovanni » Thu Sep 13, 2018 6:21 pm

Looking at your stack trace apparently there are calls to ChibiOS.

Giovanni

fotis
Posts: 24
Joined: Mon Apr 04, 2016 7:04 pm
Has thanked: 1 time

Re: Priority order violation - Asserion fails

Postby fotis » Thu Sep 13, 2018 6:30 pm

Yes, but as you see in my stack trace, there are no calls to LWIP ;)

I have implemented all these functions. They may call LWIP internally (protected as needed), but LWIP is not able to call any Chibios functions (i.e. NO_SYS=1).

In this abstraction layer, I only use the following functions:

Code: Select all

#define OS_system_lock()                     syssts_t sts = chSysGetStatusAndLockX()
#define OS_system_unlock()                     chSysRestoreStatusX(sts)
#define OS_yield()                           chThdYield()

typedef mutex_t OS_mutex_t;
#define OS_mutex_init(mtx)                     chMtxObjectInit(mtx)
#define OS_mutex_lock(mtx)                     chMtxLock(mtx)
#define OS_mutex_unlock(mtx)                  chMtxUnlock(mtx)


As you see in the stack trace, there is a call to chMtxLock(), before entering LWIP.

fotis
Posts: 24
Joined: Mon Apr 04, 2016 7:04 pm
Has thanked: 1 time

Re: Priority order violation - Asserion fails

Postby fotis » Thu Sep 13, 2018 6:31 pm

Clarifying. Of course I may use Chibios wrongly in a way that I do not understand.

I am just saying that, if there is a bug, it is mine and not internal to LWIP.

Also note that this problem does not happen to the same thread every time.

User avatar
Giovanni
Site Admin
Posts: 11152
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 391 times
Been thanked: 322 times
Contact:

Re: Priority order violation - Asserion fails

Postby Giovanni » Thu Sep 13, 2018 7:09 pm

There now much ways to make that assertion happen:

1) IRQ priorities above the limit (0..2).
2) Calling an I-class without reschedule.

1 is ruled out by your test with simplified priority, find all places where you call I-class (and S-class just in case).

Are startup files and everything else those provided with ChibiOS?

Giovanni


Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 2 guests