This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHXL-CC1352R1: scifWaitOnNbl

Part Number: LAUNCHXL-CC1352R1


Hi team,

Here's an issue from the customer may need your help:

  * \b Important: Unlike the ALERT event, the READY event does not generate MCU domain and System CPU
  * wake-up. Depending on the SCIF OSAL implementation, this function might not return before the
  * specified timeout expires, even if the READY event has occurred long before that. To avoid such
  * delays, call \c fwGenAlertInterrupt() from the task code block that \ref scifWaitOnNbl() is waiting
  * for to complete.

" Call \c fwGenAlertInterrupt() from the task code block that \ref scifWaitOnNbl() is waiting for to complete." What is the purpose of this statement?

Looking like want to add fwGenAlertInterrupt() to the sensor controller studio. But how to associate with scifWaitOnNbl() is waiting for to complete?

Could you help check this case? Thanks.

Best Regards,

Cherry

  • Hi Cherry, Please can you mention in what context the comments have been made? In which project was this found?

  • Hi Sid,

    Thanks for your support.

    It's in the scifWaitOnNbl function of scif_framework.c and can be found in multi_sensor_CC1352R1_LAUNCHXL_tirtos_ccs.

    Drivers->ACCELEROMETER->scif_framework.c

    /** \brief Waits for a non-blocking call to complete, with timeout
      *
      * The non-blocking task control functions, \ref scifExecuteTasksOnceNbl(), \ref scifStartTasksNbl()
      * and \ref scifStopTasksNbl(), may take some time to complete. This wait function can be used to make
      * blocking calls, and allow an operating system to switch context when until the task control interface
      * becomes ready again.
      *
      * The function returns when the last non-blocking call has completed, or immediately if already
      * completed. The function can also return immediately with the \ref SCIF_ILLEGAL_OPERATION error if
      * called from multiple threads of execution with non-zero \a timeoutUs.
      *
      * \b Important: Unlike the ALERT event, the READY event does not generate MCU domain and System CPU
      * wake-up. Depending on the SCIF OSAL implementation, this function might not return before the
      * specified timeout expires, even if the READY event has occurred long before that. To avoid such
      * delays, call \c fwGenAlertInterrupt() from the task code block that \ref scifWaitOnNbl() is waiting
      * for to complete.
      *
      * \param[in]      timeoutUs
      *     Maximum number of microseconds to wait for the non-blocking functions to become available. Use a
      *     timeout of "0" to check whether the interface already is available, or simply call the control
      *     function (which also will return \ref SCIF_NOT_READY if not ready).
      *
      * \return
      *     \ref SCIF_SUCCESS if the last call has completed, otherwise \ref SCIF_NOT_READY (the timeout
      *     expired) or \ref SCIF_ILLEGAL_OPERATION (the OSAL does not allow this function to be called with
      *     non-zero \a timeoutUs from multiple threads of execution).
      */
    SCIF_RESULT_T scifWaitOnNbl(uint32_t timeoutUs) {
        if (HWREG(AUX_EVCTL_BASE + AUX_EVCTL_O_EVTOAONFLAGS) & AUX_EVCTL_EVTOAONFLAGS_SWEV0_M) {
            return SCIF_SUCCESS;
        } else {
            return osalWaitOnCtrlReady(timeoutUs);
        }
    } // scifWaitOnNbl

    Thanks and regards,

    Cherry

  • Hi Cherry, 

    The task control functions scifExecuteTasksOnceNbl(), do not block the execution and return immediately. But you can call these functions only once at a time.

    For example, you cannot call  scifExecuteTasksOnceNbl() twice, consecutively without waiting in between the two calls. You wait between these two calls with scifWaitOnNbl(timeout).

    When the CPU is waiting with scifWaitOnNbl(), it is possible that it goes to sleep. The CPU does not wake up if the sensor controller only posts a READY event and needs an ALERT event to wake up.

    If you do not have fwGenAlertInterrupt() in the sensor controller code in the task called by scifExecuteTasksOnceNbl(), the task only generates the READY event and thus the CPU wakes up only on the timeout. But maybe the task has finished executing much before this timeout. 

    If you want the CPU to wake up as soon as the task on the sensor controller is completed, you can have the fwGenAlertInterrupt() to generate an ALERT event. This wakes up the CPU. 

    Regards,

    Sid