CC2652R: CC13x2/CC26x2 RF Driver missing callbacks for 802.15.4 FG commands

Patrick Lazik1

Part Number: CC2652R

I have been building an application using the SimpleLink CC13x2 26x2 SDK v4.30.0.54, using TI's RF driver to schedule IEEE 802.15.4 commands using RF_scheduleCmd(). The architecture of my application requires that the RF_Callback callback submitted to RF_scheduleCmd() is always executed, which I assume should be the normal operation of the RF Driver? In my setup I have an IEEE RX command running in the background and am scheduling an IEEE TX command roughly every 20ms. I have noticed that occasionally a callback for a TX command being completed is missed.

Looking at the RFCC26x2_multiMode.c code, I have noticed that RF_dispatchNextCmd(), which is called whenever the HWI RF_hwiCpe0Active() gets executed, does not account for the scenario where both an IEEE FG and a BG command are marked as current commands in the RF_cmdQ struct. In this case RF_cmdQ.pCurrCmdFg is overwritten with the next pending FG command and never gets moved to the RF_cmdQ.pDone list, which prevents the RF_radioOpDoneCb() from executing the callback associated with the overwritten FG command.

I have added the line with the comment "//MODIFIED" to RF_dispatchNextCmd() below so that it also checks for the missing scenario, which has resolved the issue in my preliminary testing, however, I am wondering if this would have any adverse effects on the driver?

static void RF_dispatchNextCmd(void)
{
    bool doDispatchNow   = false;
    RF_Cmd* pConflictCmd = NULL;
    RF_Cmd* pNextCmd     = (RF_Cmd*)List_head(&RF_cmdQ.pPend);
    bool validTime = false;
    uint32_t dispatchTimeClockTicks = 0;

    /* Decide whether to schedule the next command or not. */
    if (pNextCmd)
    {
       /* Either no commands are active, and we will execute */
       if (NULL == RF_cmdQ.pCurrCmdFg && NULL == RF_cmdQ.pCurrCmdBg)
       {
           doDispatchNow = true;
       }
       /* Or the current client wants to execute in the foreground on top of a background command */
       else if (RF_cmdQ.pCurrCmdBg
                && (RF_cmdQ.pCurrCmdBg->pClient == pNextCmd->pClient)
                && (pNextCmd->flags & RF_CMD_FG_CMD_FLAG)
                && RF_cmdQ.pCurrCmdFg == NULL)  // MODIFIED: If there is a FG command running, don't dispatch now
       {
            /* Try to execute the foreground command. */
            doDispatchNow = true;

            /* Be sure that the background command is started within the RF core.
                This is to avoid race condition. */
            while ((RF_cmdQ.pCurrCmdBg->pOp->status == IDLE) ||
                    (RF_cmdQ.pCurrCmdBg->pOp->status == PENDING));
        }
        /* Or there is conflict. */
        else
        {
            /* By default let current command finish. */
            doDispatchNow = false;
        }

       LOG_DEBUG("DD=%u\r\n", doDispatchNow);
    }

...

over 4 years ago

0 Ryan Brown1 over 4 years ago

TI__Guru**** 211047 points

Hi Patrick,

Thank you for sharing your findings with us. 20 ms is quite the fast pace for IEEE TX instructions. In the 15.4-Stack application, RF TX packets are not scheduled until the previous one is completed (instead of back-to-back which would require two RF TX command instances). Can you please describe how your applications schedules RF TX packets? Do you use one or two RF TX command instances (variables) to schedule TX packets? And do you wait until the previous RF TX packet is completed before scheduling the next command?

Otherwise, your workaround is sensible and does not appear to pose any immediate problems.

Thanks,
Ryan

0 Patrick Lazik1 over 4 years ago in reply to Ryan Brown1

Prodigy 30 points

Ryan,

Thanks for the response. I have pools of several RF TX/RX command instances that I submit to the RF Driver, which allows me to schedule more complex command chains. Once a command is done or failed, it is put back into its pool using the callback submitted to the RF driver, hence why it is necessary in my design to ensure that the callbacks are always called. I never have the same instance of an RF command submitted to the RF driver while it is still running/waiting to run, but multiple different 802.15.4 TX command instances may scheduled with the driver before they are all run. I'm seeing the issue when I am doing the following:

1. Run continuous 802.15.4 RX command

2. Schedule 802.15.4 TX command (driver automatically switches to the TX command and then back to RX once it is time to run TX)

3. Wait for RX of a response

4. If no response is received, schedule another TX command (this is another separate TX command instance from the command pool)

It seems like there are cases where the TX command from 4. is submitted to the RF Core before the callback from 2. has run, leading to the issue where RF_cmdQ.pCurrCmdFg is overwritten and therefore the callback from 2. never happens.

-Patrick

0 Ryan Brown1 over 4 years ago in reply to Patrick Lazik1

TI__Guru**** 211047 points

Hey Patrick,

Thank you for further explaining. Multiple RF TX commands can be scheduled in RF_CmdQ. The 15.4-Stack applications doesn't have this case to schedule multiple RF TX commands in the RF_cmdQ and thus does not observe this issue. Your fix is a good suggestion which the Software Development Team will further consider.

Regards,
Ryan

Sub-1 GHz

Sub-1 GHz forum

CC2652R: CC13x2/CC26x2 RF Driver missing callbacks for 802.15.4 FG commands