SemWait in the HIGHPRIO thread

[bxm]

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()?

[Giovanni]

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?

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

[bxm]

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]

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

[Giovanni]

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

[bxm]

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.