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.

RTOS/CC2640R2F: GAP_endDiscoverable in peripheral_observer exception in RF driver

Part Number: CC2640R2F
Other Parts Discussed in Thread: CC2650

Tool/software: TI-RTOS

Dear TI support,

I am working on a project based off of simpler_peripheral_observer using SDK 1.50.0.58 and am running into some troubles. My application is sending non-connectable advertisements and scanning for other devices continuously. This seems to work pretty well, except for the fact that sometimes I get an HCI_BLE_HARDWARE_ERROR_EVENT_CODE stack assert, which I am for now ignoring as it is being handled in a separate post.

What worries me more is that I sometimes get an exception in my application which seems to happen inside the RFCC26XX_singleMode function. I have attached the exception call stack:

It seems to be a timing issue in the RF driver, as my stack and heap aren't broken, I have HEAP_METRICS enabled and have included the task callstack:

The only thing that stands out is that my application has just called GAP_endDiscoverable(), but I am not sure if this triggers the exception as I do a lot of end_discoverable in my application. Is there any clue as to why this is happening? Is the stack unable to cope with a lot of GAP_ calls while scanning at the same time?

Thank you for your answer.

Best regards,

Mattia Fiumara

  • Hello Mattia Fiumara,

    Are you calling GAP_endDiscoverable() from a SWI / HWI context?

    Take note from the BLE SW User's Guide that you cannot make ICall API calls (i.e., protocol stack API) from a SWI or HWI context . Could you please share that piece of code?

    Thanks,

    David
  • Hi David,

    Thank you for your answer. It is not obvious from the call stack I have included but GAP_endDiscoverable() is called from a task context here:

    My main thread is Application_thread, which calls Advertiser_stop which calls GAPRole_SetParameter in the peripheral_observer profile. I have not modified peripheral_observer. The peripheral_observer profile then calls GAP_endDiscoverable. Advertiser_stop has the following lines of code:

    uint8_t advertDisable = FALSE;

    /* Disable All Advertisements */
    GAPRole_SetParameter(GAPROLE_ADVERT_ENABLED, sizeof(uint8_t), &advertDisable);
    GAPRole_SetParameter(GAPROLE_ADV_NONCONN_ENABLED, sizeof(uint8_t), &advertDisable);

    Thanks for any clear-up.

    Best regards,

    Mattia

  • Hi David,

    I inspected the code a little bit more and there were some locations in which I am calling ICall_malloc in a hwi context (from a timer callback). Do you think this could have been the cause for this error? I have removed these calls now and am now testing for RF Driver erros in the new set-up. Thanks for the help.

    Best regards,

    Mattia

  • David,

    After careful inspection of the codebase, I have removed all ICall API calls from HWI / SWI interrupts. I have ran more tests and have found the same exception occuring in the RF driver. It seems to happen when I try to switch from connectable advertisements to non-connectable advertisements. Could it be caused by switching of advertisement types? I am switching as follows:

    First I stop any current advertisements in the following manner:

    uint8_t advertDisable = FALSE;
    GAPRole_SetParameter(GAPROLE_ADVERT_ENABLED, sizeof(uint8_t), &advertDisable);
    GAPRole_SetParameter(GAPROLE_ADV_NONCONN_ENABLED, sizeof(uint8_t), &advertDisable);

    Then I set new advertisement data:

    GAPRole_SetParameter(GAPROLE_ADVERT_DATA, .....

    Then I schedule either non-connectable advertisement or connectable advertisement, depending on what I need. In the case of non-connectable advertisements I do the following two API calls:

    uint8_t advertDisable = TRUE;
    GAPRole_SetParameter(GAPROLE_ADV_EVENT_TYPE, sizeof(uint8_t), GAP_ADTYPE_ADV_NONCONN_IND);
    GAPRole_SetParameter(GAPROLE_ADV_NONCONN_ENABLED, sizeof(uint8_t), &advertEnable);

    In the case of connectable advertisements I do the following two calls:

    uint8_t advertDisable = TRUE;
    GAPRole_SetParameter(GAPROLE_ADV_EVENT_TYPE, sizeof(uint8_t), GAP_ADTYPE_ADV_IND);
    GAPRole_SetParameter(GAPROLE_ADVERT_ENABLED, sizeof(uint8_t), &advertEnable);

    Thanks for any feedback.

    Best regards,

    Mattia
  • Hi David,

    I am still encountering this issue. I am seeing this issue when switching from connected advertisements to unconnected advertisements and back in my application. It happens when calling GAP_EndDiscoverable in the application.

    I am quite certain it's a bug in the RF driver in SDK 1.50.00.58. Please take a look at line 2092 in CC26XX_singlemode.c where a possible null pointer is being dereferenced. The exception occuring in my first post demonstrates this issue (pOpFirstPend's address value is 0xffffffff).

    I am using a custom patched version of the driver which fixes this problem (attached below), but I expect an official patch coming from TI. Could you provide me with a date on when to expect this patch? We are already using this feature in our product based on the CC2650 and intend to keep using this feature with the new SDK. Thank you for your answer.

    Best regards,

    Mattia

    --- <unnamed>
    +++ <unnamed>
    @@ -2089,9 +2089,13 @@
     
             /* Setup FS command to follow SETUP command */
             rfc_CMD_FS_t* pOpFs;
    -        RF_Cmd* pOpPend = Q_peek(&cmdQ.pPend)->pOp;
    -
    -        if ((pOpFirstPend->commandNo == CMD_FS) || (pOpFirstPend->commandNo == CMD_FS_OFF))
    +        RF_Cmd* pOpPend = Q_peek(&cmdQ.pPend);
    +        RF_Op* pOpFirstPend = NULL;
    +
    +        if (pOpPend)
    +          pOpFirstPend = pOpPend->pOp;
    +
    +        if (pOpFirstPend && (pOpFirstPend->commandNo == CMD_FS) || (pOpFirstPend->commandNo == CMD_FS_OFF))
             {
                 /* First command is FS command so no need to chain an implicit FS command
                    Reset nRtc1 */
    
    

  • David,

    Could you provide me with a response? Or pass the issue to the CC26XX Driver team?

    Best regards,

    Mattia
  • Hi Mattia,

    My apologies for the lack of response, I sent this request to the driver team and I'll let you know as soon as I get any word back from them.

    Best regards,

    David