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-CC26X2R1: How the function zspbProcessEvent be called?

Part Number: LAUNCHXL-CC26X2R1
Other Parts Discussed in Thread: Z-STACK

I am porting TI Z-Stack Linux Gateway to ARM platform, but have some issue.

I want to know how the function zspbProcessEvent( ) be called and where to add code for debug info. Thanks.

Regards,

Peter.

  • Hi Peter,

    You can debug this function from zstackpb.c where it is established.

    /*********************************************************************
     * @fn      zspbProcessEvent
     *
     * @brief   ZStack Protobuf Task event processor.  This function
     *          is called to process all events for the task.  Events
     *          include timers, messages and any other user defined events.
     *
     * @param   task_id  - The OSAL assigned task ID.
     * @param   events - events to process.  This is a bit map and can
     *                   contain more than one event.
     *
     * @return  none
     */

    It is used in osal_zstack_server_znp.c which invokes the initialization function for each task.  Several relevant events are set inside znp_misc.c before being transferred with osal_msg_send.  Examples include ZDO_CB_MSG, AF_DATA_CONFIRM_CMD, and AF_INCOMING_MSG_CMD.

    Regards,
    Ryan

  • The zspbProcessEvent( ) not called might induced from Hal_ProcessPoll( ), which called in osal_run_system( ), cannot return after osal_msg_send & osal_msg_enqueue_push & osal_set_event with SYS_EVENT_MSG were called. I debug with adding debug info before & after Hal_ProcessPoll( ). Any reason can be blocked in Hal_ProcessPoll( ) even when osal_set_event did call?

    OSAL,c code uses intensive HAL_ENTER_CRITICAL_SECTION & HAL_EXIT_CRITICAL_SECTION. But I don't understand why these APIs can work as it use HAL_DISABLE_INTERRUPTS which use halInterupts? I did not modify OSAL related codes when porting to ARM platform as it was compiled OK.

    Peter.

  • Hal_ProcessPoll should be waiting in the poll function until a valid SetPollTimeOut is given, which should occur from osal_set_event.  Failure to do so could indicate an issue with the poll functionality.

    hal_mcu.h shows that critical sections are mostly benign for this platform, as they only affect the local halInterupts variable used by HAL_INTERRUPTS_ARE_ENABLED but not referenced anywhere else in the project.

    Regards,
    Ryan

  • Hi Ryan,

    Thanks for feedback. I will check poll functionality on my ARM platform.

    As for hal_mcu.h, do you mean HAL_ENTER_CRITICAL_SECTION & HAL_EXIT_CRITICAL_SECTION don't have real function? I just curiously if trouble might occur when tasksEvents is not protected well. I think tasksEvents should be protected. Am I right?

    Regards,

    Peter.

  • HAL_[ENTER/EXIT]_CRITICAL_SECTION do not have any real functionality implemented in this example.  They represent a placeholder for developers to add their own use per their platform's requirements.

    Regards,
    Ryan

  • Hi Ryan,

    You said: "They represent a placeholder for developers to add their own use per their platform's requirements." As I think tasksEvents should be protected or some race conditions might happen. I have three more questions.

    1. Does it imply "X86 PC platform" should have their implementations for this placeholder? Current TI source did not implement it. How come it can work?

    2. Do you mean OSAL functions implementation is a must when porting to ARM platform?

    3. How do I know the platform dependent placeholders in this source code?

    Regards,

    Peter.

  • 1. As shown by the example, this feature is not a requirement for operation.  It is useful during the Z-Stack implementation on MCUs to disable/restore hardware interrupts while performing critical operations.

    2. This API allows the software components in the Z-stack to be written independently of the specifics of the operating system, kernel or tasking environment (including control loops or connect-to-interrupt systems).  In theory it may be possible to remove this layer, but this would be a large task since it is used so heavily by the project resources.

    3. That is a good question, however one of the drawbacks of this example is that these dependencies have not been made entirely clear.  You can follow the package_builder TARGET_PLATFORM definitions and Makefile compile flags for moroe information.

    Regards,
    Ryan

  • Hi Ryan,

    Thanks for your explanation & confirmation for (1) & (2). I make note for (3) and will investigate when I have time later.

    I found the reason why be blocked in Hal_ProcessPoll( ) function when there is a osal_set_event, but I don't know why it happen on my ARM platform.

    The reason is: use sigqueue( ) to signal poll( ) is not workable. It becomes normal when I replace with kill( ) API.

    The difference between these two APIs is no argument passed in for kill( ) API. But it works.

    Regards,

    Peter.