• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 3 answers
  • Subscribers 51 subscribers
  • Views 441 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: BLE advertisement with partial payload observed after reset

shanmathi p
Intellectual 330 points
Part Number: CC2640R2F

Tool/software: TI-RTOS

Hello,

I am using BLE SDK version v2.20.00.49 with CC2640R2F in my project.

Steps followed after calling SysCtrlSystemReset() from the software.

 1. Jump from Bootloader to Application.

2. Delay for about 5 seconds in the application.

3. Chip initialization and PIN settings configuraiton.

4.  /* Initialize ICall module */
    ICall_init();

    /* Start tasks of external images - Priority 5 */
    ICall_createRemoteTasks();

    /* Kick off profile - Priority 3 */
    GAPRole_createTask();

    /* Ble Task - Priority 2 */
    BLETask_Create();

    /* App task - Priority 1 */
   App_init();

    /* Enable interrupts and start SYS/BIOS */
    BIOS_start();

Watchdog is enabled during BIOS startup and cleared in idle task.

Thus an active delay is added before BIOS_START() call.

BLE advertisement  is enabled and disabled only in the application context.

Observation :

After reset a very short BLE advertisement packet is seen which has only partial data in its payload.

Later the advertisements are proper when application task is running.

Any clue regarding the unexpected BLE advertisement after a reset would be of great help.

Thanks and Regards,

Shanmathi P

  • 0
    Intellectual 330 points

    Hello,

    Please find the attachment for the sniffed logs after reset.

    Only the following values are updated, during the very first advertisement.

    •  Flags for discovery mode - GeneralDiscoverable, BrEdrNotSupported.

    BLE_ADV_AFTER_RESET_SNIFFED_LOGS.zip

  • 0 in reply to shanmathi p
    TI__Mastermind 33460 points
    Hi,

    You mention a bootloader, is this the BIM project that is provided in the SDK or is this custom SW
    What source code have you modified and can you provide code (that runs on LaunchPad) to reproduce this issue?
  • 0 in reply to Sean2
    Intellectual 330 points

    Hi,

    We use a custom SW fro BIM in our project, which does the verification of OAD image and jumps to application.Communication is not enabled in BIM.

    The issue is seen only when we introduce a delay as mentioned in Step 2 during application startup.

    When Step 2 is not executed, we are not getting any truncated BLE advertisement packets as attached in the sniffer logs.

  • 0 in reply to shanmathi p
    TI__Mastermind 33460 points
    Hi,

    If step #2 from above seems to be causing the partial advertisement packets to be sent out can you give more information on exactly how you're doing the "Delay for about 5 seconds in the application". Perhaps this is interfering with the stack somehow?

    Can you reproduce this on a TI sample app?
  • 0 in reply to Sean2
    Intellectual 330 points

    Hi,

    Please find the details.

    If step #2 from above seems to be causing the partial advertisement packets to be sent out can you give more information on exactly how you're doing the "Delay for about 5 seconds in the application". Perhaps this is interfering with the stack somehow?

    -  We use an active delay in our software. We are not using any rtos calls.

       uint32_t waitTimeCounter = 40000000;

        while (waitTimeCounter > 1)
        {
            waitTimeCounter --;
        }

    Can you reproduce this on a TI sample app?

    - The issue was not observed in TI example project - I checked by building  SimplePeripheral application using TI SDK.

    My understanding is that RF core (Cortex-M0) is controlled by the CC2640R2F's main CPU (Cortex-M3).

    So what could be the possible cause for BLE advertisement at this very early stage?

    Is there any particular sequence to be followed, to switch off BLE completely before performing a reset?

  • 0 in reply to shanmathi p
    TI__Mastermind 33460 points
    Hi,

    Have you verified that the advertisement is coming after the reset and in fact is not sent right as the device is resetting (because the device reset in the middle of a TX operation)?

    In general I would recommend waiting to gracefully stop advertising using the associated GAPRole calls and events before resetting.
    This would be sure that advertising has ceased before resetting.

    A more draconian way would be to issue HCI_ResetCmd() which will reset the Link Layer or HCI_EXT_ResetSystemCmd() which will reset the link layer and eventually call SysCtrlSystemReset after, this will trigger a reboot.
  • 0 in reply to Sean2
    Intellectual 330 points
    Hi Sean,

    Thanks for your suggestions.

    Regarding when the advertisement is seen :
    It is captured after the system undergoes reset.
    Verified by debugging that the advertisement packet is enabled, after reset, after the creation of BLE task creation in main and before the application task begins to run.

    Current procedure followed in app before reset :
    Advertising is stopped and connection is terminated.
    - GAPRole_SetParameter( GAPROLE_ADVERT_ENABLED, sizeof(uint8_t), &advDisable);
    and GAPRole_TerminateConnection(); API's are called.

    Tried using HCI_ResetCmd() and HCI_EXT_ResetSystemCmd() API's . Still the issue is observed.


    We use split image configuration in our project. Are there any possibility that these invalid packets are from the link layer duing BLE task creation?
  • 0 in reply to shanmathi p
    TI__Mastermind 33460 points
    >> We use split image configuration in our project. Are there any possibility that these invalid packets are from the link layer duing BLE task creation?

    Perhaps there is some unexpected consequence coming out of reset. Can you see if the RF driver is being invoked at all after task creation but before GAPROLE_ADVERT_ENABLED is called.