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.

CC2541 unexpectedly stops advertising while no connection is made. After an uncertain period, the advertising recovers without any intervention.

Other Parts Discussed in Thread: CC2541, BLE-STACK

I am using CC2541 on a control board for a non-parking barrier, which is named: ‘parking lock’. It’s designed to function as follow:

When the car owner drives away from the parking space, he uses his cellphone (with Bluetooth on) to rise the lock’s arm to 90 degree, in case other people parks on his space while it is empty. Then he comes back to park in, the arm will be put down by his cellphone again.

The CC2541 is used as BLE interface with cellphone (include Android and iOS) at the same time processor chip on board. So it is connected with :

1 LED and 1 buzzer to blink and beep while the arm is moving or other defined situation occurs;

2 pairs of photoelectric correlated cells as arm position detector;

1 motor to drive the arm;

The system is powered by lead acid battery, 6V-7AHr.

Under normal situation after powered up, the slave device (CC2541) start advertising immediately, master device (cellphone) can scan, find slave device and initiate connection, to manipulate the arm. When the connection is terminated, the slave device should continue advertising in case any master device initiates connection. While the arm is risen (in lock position), if any external force changes it’s position, the arm would automatically return to the lock position. The logic decision is made by the CC2541, too.

However, odd thing happened during application in different projects, the slave devices were found stopped advertising unexpectedly. The scenario is:

No master device (iPhone or Android phones) could not scan and find the slave, therefore no connection could be initiated or established. At this point, if the arm is pushed down, it still returns to the lock position. This concludes the system is still running, only the Bluetooth interface is malfunctioning.

When the advertising stops, power off the system and restore the power, the CC2541 advertising comes back immediately, that is when power on again, master devices could scan & find the slave device, connection could be established and the arm could be operated as designed. Or, if we leave the slave device untreated when it stops advertising, after an uncertain time, it will restore advertising by itself.

It is difficult to reproduce the scenario, as we put 30 devices under surveillance, only one piece was found stops and re-advertising. It was found stop advertising 3 times, the gap between each time is different, but the period of no advertising is precisely 2hr55min04sec.

Although just 1 was found stops advertising in the 30 devices under surveillance, the problem still exists on the devices applied on site. The frequency is not steady, only some of the devices comes across the problem more often than others. The environment is outdoor and underground parking lot, temperature is -10 to 20 degree Celsius.

We are using BLE stack ver1.4.0, 32M and 32K external OSC for power saving mode. At first, we doubt about power saving mode could leads to the problem, however after we disabled it, problem remains. Later, we doubt about the 32K OSC is not precise, and changed to RC inside, even weld the 32K OSC off, no good. Then, we doubt about the PCB route, changed the PCB design, move the 32K OSC closer to the CC2541, no good.

This problem is really kicking nuts. Hope someone could reach out hands here.



  • Hello William,

    Although upgrading to BLE-Stack 1.4.1 is the preferred solution, please see this thread with guidance for adjusting HAL_SLEEP_ADJ_TICKS on your board:

    This would be a good first step.

    Best wishes
  • Dear JXS,

      Thank you for prompt reply. Is there any more information on this adjusting? On the other hand, the example is really different from our problem.  Have you ever meet this advertising stop ?

  • user46.......and some more numbers,

    What is happening is the stack is keeping track of how long the advertisement should be off using a timer. You are in your off mode and then a higher priority task is taking place for example (reading an input?, another timer interrupt?, anything that would be on the task manager queue could do this) but what I noticed is that there is no underflow protection on the timers. So if you are less than say (random number) 20 clocks away from 0, where 0 is the time that the osal_timer will trigger and a higher priority task takes place then the timer will be decremented and actually rollover  to 0xFFFF. Then it won't fire again for a really long time.

    1. Add under flow protection greater than what is already existing

    So if(timerValue < (someNumberYouChooseThatMakesYouFeelSafe))


    timer1Pending = TRUE


    Then check that bool.

    Also I'm assuming you arent using the ADVERT_OFF_TIME parameters and just controlling the advertising status using application implemented osal timers that control your on/off sequence.

    2. A watchdog timer is necessary b/c there are more bugs in the BLE stack on these CC2541 devices and it will save you. FYI watchdog timer doesnt clock in sleep so you need to be able to wake up externally on periodic basis to prevent those edge cases too.

  • That value should be checked before going to sleep btw, that's where I would see that problem. So where the stack enters sleep you will want to check your underflow protection parameters on your timers.
  • Hi Peyton,
    Thanks for your guide. Seems like a very reasonable cause of our problem. Will try to slove it in this direction. Come back soon with result.

  • Our project meet exactly the same symptom (period of no advertising is around 2hr40~50mins). Search E2E knowledge base. Try suggestions as below but it doesn't work.

    1. comment out HCI_EXT_ClkDivOnHaltCmd( HCI_EXT_ENABLE_CLK_DIVIDE_ON_HALT )

    2. Setting HAL_SLEEP_ADJ_TICKS to 35

    Has the problem been resolved? What is the major root cause of BLE advertising signal disappearing? Thank you...
  • KH,

    The symptom you described was addressed in BLE-Stack v1.4.1 (May 2015) with the following fix:

    - Fix for possible race condition T2ISR vs T2E1 on slow wakeups

    Best wishes
  • JXS,

    Thanks for your input. In my another ticket, the recommendation is commenting out HCI_EXT_ClkDivOnHaltCmd( HCI_EXT_ENABLE_CLK_DIVIDE_ON_HALT ) and HCI_EXT_HaltDuringRfCmd(HCI_EXT_HALT_DURING_RF_DISABLE). See detail:

    We did apply the recommendation before the ticket creation. But it doesn't work.
    With you info, Can we conclude the complete solution should include follows?
    1.) Later BLE-Stack v1.4.1
    3.) Setting HAL_SLEEP_ADJ_TICKS to 35 (from another discussion)

    When this unexpectedly no BLE advertising happened, the period of time is indeed 2h40~50mins each time. We have no clue why it happened and what factors triggered BLE module entering this no advertising loop? What is 2h40~50mins timing meaning in BLE-Stack v1.4.0?

    Since you've mentioned it relates "Fix for possible race condition T2ISR vs T2E1 on slow wakeups", Could you explain more details to enrich our knowledge? Thank you.

  • KH,

    This was related to a race condition manifesting from slow wake ups from sleep (PM2). The HAL_SLEEP_ADJ_TICKS is merely a way to avoid the issue, while the actual fix is in BLE-Stack v1.4.1. The value may vary from board to board. It is worth noting that this condition did not occur on TI reference HW; it was only observed on custom HW .

    Have you upgraded your board to 1.4.1?

    Best wishes
  • Hi JXS,

    Thanks for your explanation. We have samples running BLE-Stack v1.4.2 now and will increase test samples shortly. Keep watching before widely field deployment.

    With BLE-Stack v1.4.0, our observation shows
    1.) Problem happened when Peripheral with connectable advertising profile
    2.) Problem doesn't show when Peripheral with non-connectable advertising profile
    3.) Failure percentage vary depending on the each field site (Floors, Cement/Steel-plated ceiling, open/close boundary, RF interferences i.e. numbers of Wifi AP, BLE devices etc...)
    4.) Hard to duplicate in the lab

    Could you share your thoughts/ideas what environmental factors can trigger BLE module entering this race condition? and Why non-connectable advertising profile can make difference?

  • 1.) Problem happened when set Peripheral with connectable advertising profile
    2.) Problem doesn't show when set Peripheral with non-connectable advertising profile