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.

CC2652P: Time-sharing uses 15.4 protocol stack and BLE RF interface. When using 15.4 protocol stack to send data or search network, it will enter "Main_excHandler"

Part Number: CC2652P

If the BLE RF interface does not sleep, there will be no exception. Just set sleep in BLE RF, then use 15.4 protocol stack to put cpu into "Main_excHandler"。

SDK Version is 4.40.4.04。

BLE RF code:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
void ble_nc_adv_tx(void)
{
static uint16_t ble_tx_seq = 0;
static RF_Object rfObject;
static RF_Handle rfHandle = 0;
RF_InfoVal val;
uint8_t chan = 1;
RF_Params rfParams;
RF_Params_init(&rfParams);
ble_adv_aoa_t *p_ble_aoa = (ble_adv_aoa_t *)ble_aoa_buf;
p_ble_aoa->user_header = 0x9527;
p_ble_aoa->tag_id = product_sn.card_id;
p_ble_aoa->seq = ble_tx_seq++;
p_ble_aoa->ble_period_10ms = ble_period_ms / 10;
p_ble_aoa->activity_flag = 0;
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Hello,

    Since it appears you are time sharing between 2 stacks, is there a reason you aren't using DMM (Dynamic Multi-protocol Manager). You can read more about how to use DMM here: https://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_5_20_00_52/docs/dmm/dmm_user_guide/html/dmm-guide/index-cc13x2_26x2.html 

    Regards,

    Daniel

  • Since we only need BLE to send and receive simple data, without using the BLE protocol stack and DMM, data can be sent more flexibly and the FLASH occupies less。Is there a way to solve the above problem?

  • Hello zhang,

    Can you please share how your are setting the BLE RF to sleep and switching operation to the 15.4-Stack protocol?  Have you gathered any further information from using the CCS debugger ROV?

    https://e2e.ti.com/f/1/t/882697 
    https://e2e.ti.com/f/1/t/821848 

    Regards,
    Ryan

  • Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    void ble_nc_adv_tx(void)
    {
    static uint16_t ble_tx_seq = 0;
    static RF_Object rfObject;
    static RF_Handle rfHandle = 0;
    RF_InfoVal val;
    uint8_t chan = 1;
    RF_Params rfParams;
    RF_Params_init(&rfParams);
    ble_adv_aoa_t *p_ble_aoa = (ble_adv_aoa_t *)ble_aoa_buf;
    p_ble_aoa->user_header = 0x9527;
    p_ble_aoa->tag_id = product_sn.card_id;
    p_ble_aoa->seq = ble_tx_seq++;
    p_ble_aoa->ble_period_10ms = ble_period_ms / 10;
    p_ble_aoa->activity_flag = 0;
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    just add “ RF_flushCmd(rfHandle, RF_CMDHANDLE_FLUSH_ALL, abortGraceful);

    RF_yield(rfHandle);”,call 15.4 stack api  will put cpu into "Main_excHandler"

  • RF_yield is not enough to fully close the BLE PHY in order to switch to 15.4-stack PHY operation, as it only signals that the radio client is not going to issue more commands in a while.  You will need to use RF_close so that you can then change the RF parameters before calling RF_open again.  I also recommend waiting on the result of the RF_runCmd before flushing.  Please review the Proprietary RF User's Guide and rflib APIshttps://e2e.ti.com/f/1/t/963331 

    Regards,
    Ryan

  • Now we have removed the 15.4 protocol stack and only used the RF interface for testing. First, we enter 15.4 mode. When the button is pressed, it switches to ble mode. When the button is pressed again, it switches to 15.4 mode. In the process of switching to 15.4 mode The code in the execution of "RF_runCmd(rfHandle, (RF_Op*)&RF_cmdFs, RF_PriorityNormal, NULL, 0);" will not return, and will jump to "Main_excHandler".

    SDK verison:4.20.0.35

    ble mode code:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    void ble_cfg(uint8_t chan,uint16_t br)
    {
    RF_Params rfParams;
    RF_Params_init(&rfParams);
    zgb2g4_close();
    if(rfHandle)
    {
    /* Request access to the radio */
    (void)RF_cancelCmd(rfHandle, rxCmdHndl, 0);//ABORT_ABRUPT
    (void)RF_pendCmd(rfHandle, rxCmdHndl, 0);
    //uint8_t abortGraceful = 1;
    //RF_flushCmd(rfHandle, RF_CMDHANDLE_FLUSH_ALL, abortGraceful);
    RF_close(rfHandle);
    }
    debug_printf("\r\nbefore ble open,firstly close:%d\r\n",rfHandle);
    // memset(&rfObject,0,sizeof(RF_Object));
    rfHandle = RF_open(&rfSnifferObject, &RF_prop, (RF_RadioSetup*)&RF_cmdBle5RadioSetup, &rfParams);
    debug_printf("\r\n ble opened:%d\r\n",rfHandle);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    15.4 mode code:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    void zgb2g4_cfg(uint8_t chan,uint16_t br)
    {
    RF_Params rfParams;
    RF_Params_init(&rfParams);
    ble_close();
    if(rfHandle)
    {
    /* Request access to the radio */
    (void)RF_cancelCmd(rfHandle, rxCmdHndl, 0);//ABORT_ABRUPT
    (void)RF_pendCmd(rfHandle, rxCmdHndl, 0);
    //uint8_t abortGraceful = 1;
    //RF_flushCmd(rfHandle, RF_CMDHANDLE_FLUSH_ALL, abortGraceful);
    RF_close(rfHandle);
    }
    debug_printf("\r\nbefore zgb open,firstly close:%d\r\n",rfHandle);
    rfHandle = RF_open(&rfSnifferObject, &RF_prop, (RF_RadioSetup*)&RF_cmdRadioSetup, &rfParams);
    debug_printf("\r\n zgb opened:%d\r\n",rfHandle);
    /* Set the frequency */
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    switch code:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    if(s_flag == 1)
    {
    void zgb2g4_init(void);
    zgb2g4_init();
    debug_printf("switch zgb\r\n");
    s_flag = 0;
    }
    else
    {
    void ble_init(void);
    ble_init();
    debug_printf("switch ble\r\n");
    s_flag = 1;
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • So you are able to open the 2.4 GHz 15.4 RF mode once, but after switching to BLE and back you are no longer able to run the command for RF_cmdFs?  What is the value of the chan parameter in both instances?  Have you considered evaluating the newest SDK version (v5.20)?  Please provide the default RF_cmdRadioSetup & RF_cmdFs structures being used.

    Regards,
    Ryan

  • 15.4 code

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    // TI-RTOS RF Mode Object
    static RF_Mode RF_prop =
    {
    .rfMode = RF_MODE_AUTO,
    .cpePatchFxn = &rf_patch_cpe_ieee_802_15_4,
    .mcePatchFxn = 0,
    .rfePatchFxn = 0
    };
    // Radio Setup Command for Pre-Defined Schemes
    static rfc_CMD_RADIO_SETUP_PA_t RF_cmdRadioSetup =
    {
    .commandNo = 0x0802,
    .status = 0x0000,
    .pNextOp = 0, // INSERT APPLICABLE POINTER: (uint8_t*)&xxx
    .startTime = 0x00000000,
    .startTrigger.triggerType = 0x0,
    .startTrigger.bEnaCmd = 0x0,
    .startTrigger.triggerNo = 0x0,
    .startTrigger.pastTrig = 0x0,
    .condition.rule = 0x1,
    .condition.nSkip = 0x0,
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    ble code

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    RF_Mode RF_prop =
    {
    .rfMode = RF_MODE_AUTO,
    .cpePatchFxn = &rf_patch_cpe_bt5,
    .mcePatchFxn = 0,
    .rfePatchFxn = 0
    };
    rfc_CMD_BLE5_RADIO_SETUP_PA_t RF_cmdBle5RadioSetup =
    {
    .commandNo = 0x1820,
    .status = 0x0000,
    .pNextOp = 0, // INSERT APPLICABLE POINTER: (uint8_t*)&xxx
    .startTime = 0x00000000,
    .startTrigger.triggerType = 0x0,
    .startTrigger.bEnaCmd = 0x0,
    .startTrigger.triggerNo = 0x0,
    .startTrigger.pastTrig = 0x0,
    .condition.rule = 0x1,
    .condition.nSkip = 0x0,
    .defaultPhy.mainMode = 0x0,
    .defaultPhy.coding = 0x0,
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • yes,Can only be configured once

  • Thanks for providing more information.  Since you call RF_postCmd (asynchronous) for Rx commands, you should be using RF_pendCmd as well to wait for RF success or failure before continuing with code execution.  Another suggestion is to use RF_runScheduleCmd (reference this E2E thread) for synchronous operation.  If these suggestions do not help, can you please provide your entire project so that I may be able to further investigate and debug?  There is also a relevant E2E thread and rfDualModeRx example you may be able to reference.

    Regards,
    Ryan