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.
Priority order violation - Asserion fails Topic is solved
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Priority order violation - Asserion fails
Try setting CORTEX_SIMPLIFIED_PRIORITY=1, does this hide the problem?
Giovanni
Giovanni
Re: Priority order violation - Asserion fails
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:
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
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Priority order violation - Asserion fails
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
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
Re: Priority order violation - Asserion fails
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?
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?
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Priority order violation - Asserion fails
Looking at your stack trace apparently there are calls to ChibiOS.
Giovanni
Giovanni
Re: Priority order violation - Asserion fails
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:
As you see in the stack trace, there is a call to chMtxLock(), before entering 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.
Re: Priority order violation - Asserion fails
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.
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.
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Priority order violation - Asserion fails
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
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
Who is online
Users browsing this forum: No registered users and 12 guests