• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 52 subscribers
  • Views 1121 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.

CC2540 Advertising stop

Mathieu Fortin
Prodigy 50 points
Other Parts Discussed in Thread: CC2541S

I’m using CC2540 with BLE stack 1.4.0 in my project. The CC2540 Is always ON and send advertising to establish connection when paired device is in range. The issue is that once a month, the CC2540 RF Core stop sending advertising. Is it a known issue?

I saw in other posts that people had the same issue as me with stopping advertising but with CC2541 instead. The solution was to upgrade BLE stack to 1.4.1 or change "#define HAL_SLEEP_ADJ_TICKS" from 25 to 35.

For CC2540, this value is already set to 35. See extract from hal_sleep.c below:
#if defined( CC2541) || defined( CC2541S )
#define HAL_SLEEP_ADJ_TICKS 25 // default sleep adjustment, in 32kHz ticks
#else // CC2540
#define HAL_SLEEP_ADJ_TICKS 35 // default sleep adjustment, in 32kHz ticks
#endif // CC2541 || CC2541S

Should I increase the value to more than 35? Which value should I use? Does anyone try different values?

  • 0
    TI__Guru** 105180 points
    Hello,

    I would recommend upgrading if you have the opportunity, but if you don't see the issue with a setting of 35 on BLE 1.4.0, then you will probably be ok. I would test the change though before deployment.

    Best wishes
  • 0
    Intellectual 820 points

    We did see a similar problem.

    Here's how we solved it:
    In xxx_init() function we register with HCI_EXT_AdvEventNoticeCmd(taskId, xxx_ADV_EVT) to send an event to the main event loop on an advertisement.  In the event loop, we increment a counter, current_adv_counter, on receipt of xxx_ADV_EVT.

    Our application also has a separate periodic task that runs every few seconds, much like SBP. In the periodic task, there is a check for a delta between our last check of current_adv_counter (stored in a variable, say prev_adv_counter) and the current value of current_adv_counter.   If current_adv_counter and prev_adv_counter is the same, our device is not functioning as expected and we reset (reboot) the device. If this heavy handed approach is not to your liking, then there are other options too.