chSysHalt("SV#8") at Vector78

[Giovanni]

Hi,

SV#8 is caused by malformed ISRs or wrong IRQ priority.

Code: Select all

 *            - SV#8, misplaced @p CH_IRQ_PROLOGUE().
 *              - Not called at ISR begin.
 *              - Called from a critical zone.
 *              .

That code is probably unrelated.

Giovanni

[vrollei]

SV#8 happens on different IRQ only after starting this thread and some calls of HAL or RT sleep/VT from this thread, which leads to SV#8 at ST, SPI DMA or SD.

System works stable without this thread,
so I am trying to find out what is wrong with thread creation code from this topic:
viewtopic.php?f=24&t=4471

[vrollei]

Is it necessary to call chSchWakeupS after chThdCreateI?

[vrollei]

In any case there is "priority order violation" error.

1. If create thread with HIGHPRIO using chThdCreateI and call chSchWakeupS system halts with: "priority order violation"
2. If do not call chSchWakeupS system halts on chSysUnlock with: "priority order violation"
3. If create thread with HIGHPRIO using chThdCreateI and call chSchRescheduleS(), system will be halted later with chSysHalt("SV#8")

How to create thread correctly using chThdCreateI?

[Giovanni]

You may use chThdCreate() without "I".

Code: Select all

/**
 * @brief   Creates a new thread into a static memory area.
 * @details The new thread is initialized and make ready to execute.
 * @post    The created thread has a reference counter set to one, it is
 *          caller responsibility to call @p chThdRelease() or @p chthdWait()
 *          in order to release the reference. The thread persists in the
 *          registry until its reference counter reaches zero.
 * @note    A thread can terminate by calling @p chThdExit() or by simply
 *          returning from its main function.
 *
 * @param[out] tdp      pointer to the thread descriptor
 * @return              The pointer to the @p thread_t structure allocated for
 *                      the thread into the working space area.
 *
 * @iclass
 */
thread_t *chThdCreate(const thread_descriptor_t *tdp) {
  thread_t *tp;

#if (CH_CFG_USE_REGISTRY == TRUE) &&                                        \
    (CH_DBG_ENABLE_STACK_CHECK == TRUE) || (CH_CFG_USE_DYNAMIC == TRUE)
  chDbgAssert(chRegFindThreadByWorkingArea(tdp->wbase) == NULL,
              "working area in use");
#endif

#if CH_DBG_FILL_THREADS == TRUE
  _thread_memfill((uint8_t *)tdp->wbase,
                  (uint8_t *)tdp->wend,
                  CH_DBG_STACK_FILL_VALUE);
#endif

  chSysLock();
  tp = chThdCreateSuspendedI(tdp);
  chSchWakeupS(tp, MSG_OK);
  chSysUnlock();

  return tp;
}

Giovanni

[vrollei]

chThdCreateSuspendedI and chSchWakeupS work fine,
but after switching to this thread there is the same result: chSysHalt("SV#8") at ST IRQ handler

[vrollei]

Hi,

what is the first version of RT kernel with new chThdCreateI signature?

[Giovanni]

First version is 16.1.x if I remember well, SV#8 is another problem, most likely related to some ISR.

Giovanni

[vrollei]

Thanks a lot!

I can not find out what is the root cause of the problem,
test thread works fine with the same IRQs.

[vrollei]

Hi!

The problem was: CH_IRQ_PROLOGUE() / CH_IRQ_EPILOGUE() called inside EXT callback.

Maybe it would be good to add any check in CH_IRQ_PROLOGUE in case of sequential call....

it is really hard to find problem without this check.