Hi, I'm trying to workout debug panic in the following scenario:
High priority thread T1 created and then sleeps on chSemWait() function;
then main thread signals to it with chSemSignal();
being the high priority, T1 immediately rescheduled, but inherits chSysLock() from chSemSignal(). As a result, any subsequent invocation of OS API causes SV#8 panic due to dbg_lock_cnt being 1. Is the behavior by design and thread must explicitly call chSysUnlock() after chSemWait()?
SemWait in the HIGHPRIO thread
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: SemWait in the HIGHPRIO thread
Both chSemSignal and chSemWait are normal functions and must be NOT called within chSysLock and chSysUnlock.
SV#8 is strange because it is related to ISRs, do you have any ISR in your code?
Giovanni
SV#8 is strange because it is related to ISRs, do you have any ISR in your code?
Code: Select all
* @details Debug APIs and services:
* - Runtime system state and call protocol check. The following
* panic messages can be generated:
* - SV#1, misplaced @p chSysDisable().
* - Called from an ISR.
* - Called from a critical zone.
* .
* - SV#2, misplaced @p chSysSuspend()
* - Called from an ISR.
* - Called from a critical zone.
* .
* - SV#3, misplaced @p chSysEnable().
* - Called from an ISR.
* - Called from a critical zone.
* .
* - SV#4, misplaced @p chSysLock().
* - Called from an ISR.
* - Called from a critical zone.
* .
* - SV#5, misplaced @p chSysUnlock().
* - Called from an ISR.
* - Not called from a critical zone.
* .
* - SV#6, misplaced @p chSysLockFromISR().
* - Not called from an ISR.
* - Called from a critical zone.
* .
* - SV#7, misplaced @p chSysUnlockFromISR().
* - Not called from an ISR.
* - Not called from a critical zone.
* .
* - SV#8, misplaced @p CH_IRQ_PROLOGUE().
* - Not called at ISR begin.
* - Called from a critical zone.
* .
* - SV#9, misplaced @p CH_IRQ_EPILOGUE().
* - @p CH_IRQ_PROLOGUE() missing.
* - Not called at ISR end.
* - Called from a critical zone.
* .
* - SV#10, misplaced I-class function.
* - I-class function not called from within a critical zone.
* .
* - SV#11, misplaced S-class function.
* - S-class function not called from within a critical zone.
* - Called from an ISR.
Giovanni
Re: SemWait in the HIGHPRIO thread
Giovanni wrote:Both chSemSignal and chSemWait are normal functions and must be NOT called within chSysLock and chSysUnlock.
Correct, but I mean that it is chSemWait acquires and not releases lock before switching to the HIGHPRIO thread. Eg., dbg_lock_cnt is zero before chSemSignal() invocation and is 1 right after chSemWait() function.
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: SemWait in the HIGHPRIO thread
Do you have ISRs in your code?
There are two possibilities:
1) A malformed ISR.
2) An ISR of an IRQ whose priority is above kernel priority and can thus preempt it (and can cause all kind of crazy errors if the ISR calls kernel code).
Giovanni
There are two possibilities:
1) A malformed ISR.
2) An ISR of an IRQ whose priority is above kernel priority and can thus preempt it (and can cause all kind of crazy errors if the ISR calls kernel code).
Giovanni
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: SemWait in the HIGHPRIO thread
bxm wrote:Giovanni wrote:Both chSemSignal and chSemWait are normal functions and must be NOT called within chSysLock and chSysUnlock.
Correct, but I mean that it is chSemWait acquires and not releases lock before switching to the HIGHPRIO thread. Eg., dbg_lock_cnt is zero before chSemSignal() invocation and is 1 right after chSemWait() function.
This is a common misconception, the unlock is called "on the other side", the sequence is always:
thread 1: lock
thread 1: switched out
thread 2: switched in
thread 2: unlock
Giovanni
Re: SemWait in the HIGHPRIO thread
Sorry for the false alarm. This was a pilot error due to supplying an invalid target for GDB which loaded corrupted image into device. Now everything works just fine.
Who is online
Users browsing this forum: No registered users and 31 guests