• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 53 subscribers
  • Views 2294 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/CC2640: Board stops advertising after random time

Robin Beilvert
Prodigy 105 points
Part Number: CC2640


Tool/software: TI-RTOS

Hi,

I am having an issue with BLE on a custom board. BLE advtertising and connectivity happens to works like a charm for hours or days, and suddenly stops to work. 

This does not seem to be due to a global board crash because the NPI layer I implemented to enable UART discussion with an other chip still responds and interacts with the SimpleBLEPeripheral task the project is based on.

 My project is based on ble_sdk_2_02_01_18. Specific code can be provided upon request, I do not know where exactly to look already.

In advance, thanks a lot for the help

Regards,

Robin B.

  • 0
    TI__Guru 56590 points
    Hello Robin,
    Have you verified the 32 kHz clock frequency accuracy on your custom board?
    Have you evaluated the CC26xx HW Troubleshooting guide on the ti ble wiki:
    processors.wiki.ti.com/.../CC26xx_HW_Troubleshooting
  • 0 in reply to Eirik V
    Prodigy 105 points

    Hi Eirik

    I checked the accuracy and stability of the 32.768kHz clock and it is perfect.

    Following the CC26xx HW Troubleshooting guide, I made a few measurements:
    DCOUPL is a steady 1.276V and the chip draws around 15/20µA which sounds correct.

    However, I have some concerns about VDDR/VDDR_RF. Two behaviours are observed along time:

    First one shows a stable 1.671V voltage on VDDR and VDDR_RF as following:

    But most of time the voltage on VDDR and VDDR_RF looks more like the following trace, with a mean of 1.609V:

    However, the boards seems to be reachable without issues when the second behaviour is observed.

    Are these voltage drops expected from the internal regulator that is being used ?

  • 0 in reply to Robin Beilvert
    TI__Guru 56590 points
    Hello Robin,
    Nicely done.

    I believe what you are seeing there is the expected difference between active mode and standby mode where there is an recharge algorithm that fill up the charge on VDDR at an interval (for more details please refer to the App note: "Measuring Bluetooth Low Energy Power Consumption").

    1)
    I will send you some patching instructions over a PM to fix a possible advertisement halt issue. Can you try this and see if that works?

    2)
    If unexpected disconnect (supervision timeout) still occurs after the above, can you try to increase the slave clock accuracy to 110 PPM (HCI_EXT_SetSCACmd( uint16 scaInPPM ) and test? The default is set to 40 PPM.
  • 0 in reply to Eirik V
    Prodigy 105 points
    Hi Eirik,

    Thank you for the patch. I just applied it and will give you feedback after some testing.
  • 0 in reply to Eirik V
    Prodigy 105 points

    Hello Eirik,

    I'm coming back to you because the patch you sent me does not seem to have solved the issue. The board was started on last Thursday and it advertised for one week without trouble.

    However, today it appears to have stopped advertising. Besides this, the UART communication and SimpleBLEPeripheral_taskFxn on the application side of the software are still running without issues on the chip.

    Do you think of  another solution, or of a mean I could use to debug this issue ? I have access to 3 GPIOs on the CC2640 and I can send UART requests for getting variables values and so on.


    Best regards,

    Robin

  • 0 in reply to Eirik V
    Prodigy 105 points

    Hello Eirik,

    Do you think of a solution I could consider to solve my problem ? Is there a way to implement some sort of watchdog that would restart the chip in case of advertising crash ? It is quite urgent for us to find a fix for this.

    Best regards,

    Robin

  • 0 in reply to Robin Beilvert
    TI__Guru 56590 points

    Hello Robin,
    Did you profile the ICall Heap Manager (heapmgr.h) (refer to developers guide)?

    You can also try to attach to running target and enable the TI-RTOS Object Viewer in search for clues:
    http://software-dl.ti.com/lprf/simplelink_cc2640r2_sdk/1.30.00.25/exports/docs/blestack/ble_sw_dev_guide/html/debugging/ble-debugging.html#ti-rtos-object-viewer

    Refer to this post for details on how to connect to running target in CCS:
    e2e.ti.com/.../1547772

  • 0
    Intellectual 535 points

    Hello Robin,

    I have a similar issue with my custom board. Did you found solution?
    I am currently using a clock that, in the event of a Advertisement failure performs a reset:

        uint8_t initialAdvertEnable = FALSE;
        // Set the GAP Role Parameters
        GAPRole_SetParameter(GAPROLE_ADVERT_ENABLED, sizeof(uint8_t), &initialAdvertEnable);
        DELAY_MS(1);
        initialAdvertEnable = TRUE;
        // Set the GAP Role Parameters
        GAPRole_SetParameter(GAPROLE_ADVERT_ENABLED, sizeof(uint8_t), &initialAdvertEnable);

    Best Regards,


    MB

  • 0 in reply to Eirik V
    Intellectual 535 points
    Hello Erik,

    Could you send me patching instructions? I have similar problem with advertisement halt issue.

    In advance, thanks :)

    Best Regards,

    MB