CC2541 freezes in connected state

ipozd

Prodigy 90 points

Other Parts Discussed in Thread: CC2541

Hi community,

My system is based on cc2541 keyfob HW design and implements custom BT LE profile.

IAR 80.30.2

IPhone 4S, iOS version iOS 9.1.

BTLE stack Version 1.4.0

I have encounter very weird behavior of my system under following stress test:

iOS application connects to system and reads characteristics
System disconnects after 30 second timeout (no read/write inactivity from application)
System starts advertising
Go to (1)

The issue I see that system “freezes” after about 1 hour of operation. It means that:

- my application task stops to receive any events, including events generated by HAL as a results to buttons presses, timeouts, etc.

- my application outputs debug log messages over HW interface. This messages includes time obtained from OSAL.

- log shows that system freezes in GAP connected state after all characteristics are read and system waits TO to disconnect. I see in log that system reads couple of time RSS value. I have callback static gapRolesCBs_t WWAG_PeripheralCBs = {GAPStateCB, RSSIChangeCB,};

to receive RSSI updates with period of 5 seconds so last two messages before system freezes are log from RSSIChangeCB() callback function.

It looks like that simple TI scheduler of all tasks is also stuck, but the weird thing that system starts operating normally after 3 hours and from logged time I do not see 3 hour discontinuity.

Initially I suspected that I have incorrect loop somewhere in my code but after analysis was not able to find any suspicious code.

Issue is quite hard to reproduce.

I appreciate any hints that may help me.

BR//

ipozd

over 8 years ago

0 JXS over 8 years ago

TI__Guru** 105180 points

Hello ipozd,

This issue is related to:
- Fix for possible race condition T2ISR vs T2E1 on slow wakeups

Which is fixed in BLE 1.4.1. Please consider upgrading to this release.

Best wishes

0 ipozd over 8 years ago in reply to JXS

Prodigy 90 points

Hi JSX,

Thank you for support!

Can you provide details in regards to this issue, please?

PS. I believe this could be also useful to others....

Thank you and best regards,

ipozd

0 JXS over 8 years ago in reply to ipozd

TI__Guru** 105180 points

Hello,

No problem! The issue is a timer race condition that occurs in the Controller. It is most commonly observed on boards that have slower wake up times as compared to the TI reference platforms. You can mitigate it from happening by modifying HAL_SLEEP_ADJ_TICKS in hal_sleep.c to increase the wake up time (i.e., add ticks). The fix for the race condition is included in the BLE 1.4.1 library (released May 2015).

Note: Searching E2E for HAL_SLEEP_ADJ_TICKS will turn up additional posts.

Best wishes

0 ipozd over 8 years ago in reply to JXS

Prodigy 90 points

Hi JSX,

Thank you!

I will try this.

Best regards,
ipoz

0 ipozd over 8 years ago in reply to ipozd

Prodigy 90 points

Hi JSX,
Quck question.
Based on forum posts value of HAL_SLEEP_ADJ_TICKS shll be increased. Does any rule exist to adjust this value according to my system design or shall I increase HAL_SLEEP_ADJ_TICKS to 35 ("one size fits all") as discussed in forum?

Best regards,
ipozd

0 Sean2 over 8 years ago in reply to ipozd

TI__Mastermind 33460 points

Hello,

Since this fix addresses the slower crystal startup times that can be observed. The default value of 25 was selected to suit our reference designs. Your crystal may have longer latency to startup. You can play around with the value based on the startup time of your crystal and find something that is optimal. As you've noticed, we found 35 to work well.

0 ipozd over 8 years ago in reply to Sean2

Prodigy 90 points

I can confirm that proposed code change has fixed the issue.

Thank you!

Best regards,
ipozd

0 Lichang Che over 8 years ago in reply to Sean2

Prodigy 180 points

Dear TI support,

Can you please advise where the fix is located? Is it in the directory Components/osal/common/OSAL_Timers.c, Components/osal/common/osal_cbtimer.c (open source directory) or in TI's .lib (binary)?

The reason I'm asking is: my client is using 1.4.0 and they want to address this issue but they don't want to take the unknown to upgrade to 1.4.1. Meanwhile they hope to keep HAL_SLEEP_ADJ_TICKS low (25) to reduce the connection time to minimize power consumption. They are contemplating just to back merge this particular change from 1.4.1 to 1.4.0 at source code level if the related change is under those open source directories.

Does this sound a feasible solution? If so, can you please point us the related files?

Thanks in advance,

Lichang

0 Lichang Che over 8 years ago in reply to Lichang Che

Prodigy 180 points

BTW, we know that low HAL_SLEEP_ADJ_TICKS could trigger the issue where advertisement could stop. In our case, we don't need a large HAL_SLEEP_ADJ_TICKS (35 or higher) because our advertising is not on going - it is turned off/on periodically (timer) or by user pushing a button. Even if it stops momentarily, external events (timer) or user will make advertisement recover.

So the question is still: is it possible just change the source code in TI directory to overcome the race condition? And where?

Bluetooth®︎

Bluetooth forum

CC2541 freezes in connected state