CC1352R: DMM: the BLE cancels sub-GHz command when the radio is requested

Hi Expert,

Setup:

• SDK:                 simplelink_cc13x2_26x2_sdk_5_30_01_01
• Sysconfig:        sysconfig_1_10_0
• Devices:           LAUNCHXL-CC1352R1F3

We are developing a sub-GHz protocol. During the Rx event, we need to start listening at a very specific time (a few milliseconds after the radio Rx settings).

As a result, the Rx procedure is as follow:

1. Set the frequency synthesizer settings
2. Post the Rx command with triggerType == TRIG_NEVER
3. Reserve the radio with RF_requestAccess for Xms
4. Waiting for Rx event
5. At the Rx event, we run RF_runDirectCmd for executing the pending command

A) Everything works fine in single protocol mode (BLE disabled). However, when the BLE is enabled, I notice that the system hangs only when the BLE calls RF_scheduleCmd between 3) and 5)

In fact:

/*
 *  ==================== RF_scheduleCmd ============================
 *  Process request to schedule new command from a particular client
 */
RF_CmdHandle RF_scheduleCmd(RF_Handle h, RF_Op* pOp, RF_ScheduleCmdParams *pSchParams, RF_Callback pCb, RF_EventMask bmEvent)
{
...

    /* If client h2 already has, reject any new commands from h. */
    if (h2 && (ClockP_isActive(&h2->state.clkReqAccess)))
    {
        /* Set the status value to schedule_error if we could not allocate space. */
        cmdHandle = (RF_CmdHandle) RF_ScheduleStatusError;

        /* Store the reason and the handle why the callback is being invoked. */
        RF_Sch.issueRadioFreeCbFlags |= RF_RADIOFREECB_CMDREJECT_FLAG;
        RF_Sch.clientHndRadioFreeCb   = h;
        
        /* ISSUE:  1) The radio is reserved by our sub-GHz protocol with RF_requestAccess
         *         2) But as soon as RF_scheduleCmd returns 'RF_ScheduleStatusError',
         *            the BLE tries again by calling RF_ratDisableChannel following by RF_scheduleCmd 
         */
    }
    else
    {

    ...     
    }
    
    ...
}

B) Also, if the radio is reserved, the BLE calls RF_ratDisableChannel for discarding our pending command:

/*
 *  ======== RF_ratDisableChannel ========
 *  Disable RAT channel
 */
RF_Stat RF_ratDisableChannel(RF_Handle h, RF_RatHandle ratHandle)
{

...

    /* If the provided handler is valid. */
    if (ratCh && ratCh->status && (ratCh->pClient == h))
    {
        /* If the RF core is active, abort the RAT event. */
        if (RF_core.status == RF_CoreStatusActive)
        {
            /* Calculate the configuration field of command (the channel we disable). */
            uint16_t config = (uint16_t)(RF_RAT_CH_LOWEST + ratCh->handle) << RF_SHIFT_8_BITS;

            /* Disable the channel within the RF core.
               It has been checked that RAT channel to be disabled is owned by the input handle h.
               Call the function that executes the disabling with RF_currClient as input argument in
               instead of h in order to force the function to accept the disable request. This is
               required in the case where the client that will disable a RAT channel is not the same
               client as currently controlling the radio.
            */
            
            /*
             * ISSUE: If the previous BLE command was graceffuly rejected, our pending command is disabled here! 
             */
            status = RF_runDirectImmediateCmd(RF_currClient, ((uint32_t)CMDR_DIR_CMD_2BYTE(CMD_DISABLE_RAT_CH, config)), NULL);
            ...
            }
        }
    }
}

As a result, the system crashes when these specific sequences occurred:

1. Set the frequency synthesizer settings
2. Post the Rx command with triggerType = TRIG_NEVER
3. Reserve the radio with RF_requestAccess for X ms
4. Waiting for Rx event ~(X-1)ms later
5. BLE tries to schedule its command with RF_scheduleCmd, but this is logically rejected (radio access requested)
6. The BLE calls RF_ratDisableChannel for discarding the pending command without notifying the command owner.
7. At the Rx event, we run RF_runDirectCmd with an invalid command handle (since the command does not exist anymore)

Questions:

1) Could you please confirm the BLE stack behavior by specifically checking how the RF_scheduleCmd error code is handled?

2) Since this behavior happens even if the BLE is paused with DMMSch_setBlockModeOn(DMMPolicy_StackRole_BlePeripheral); What's the best way for blocking any BLE radio access for a short period or until the TRIG_NEVER command is executed?

3) Why does the BLE call RF_ratDisableChannel when its command is gracefully rejected? Is there a way to avoid this from happening, eventually with a DMM/BLE stack configuration?

4) How could we be aware that our command has been discarded by RF_ratDisableChannel?

Thanks,