I’ve been looking into a problem with bluetooth low energy with the CC2564 (PAN1326) and CC2564B (PAN1326B). We have 2 devices, 1 uses CC2564 and 1 uses CC2564B. I’m using the latest version (4.0.2.2) of bluetopia from the TI website http://www.ti.com/tool/cc256xstbtblesw. I’ve also updated to the latest patch files http://processors.wiki.ti.com/index.php/CC256x_Downloads : CC2564 v2.14, CC2564B v1.6).
Usually, everything works fine, but infrequently after a BLE disconnect, BLE advertisements don’t re-start. In the code, I’m sending the HCI command to enable BLE advertisements, and the bluetooth module (CC2654 or CC2654B) sends a return value of 0 (success). However, it doesn’t actually start advertising.
I don’t have a good way to reproduce the problem. I’ve tried causing many disconnections by opening and closing a faraday cage box with the devices inside, but devices reconnect on demand. However, if I run with about 8 bluetooth devices over the weekend, I usually see 1 or 2 on Monday not sending advertisements. I’ve confirmed with the Frontline Sodera that they’re not actually sending advertisments. Log files on the devices show that the last bluetooth action performed was to start sending BLE advertisements.
I upgraded to the latest patch file on Monday. Prior to that, I saw it on both devices equally. Since then, I’ve only observed the problem on the CC2654B. That’s not a very long test period, so I’m unsure whether the latest patch fixed the problem on the CC2564 or whether I just haven’t seen problems on the CC2564 yet.
Yesterday I added some code to both devices such that I can push a button and it disables and enables advertising. One device hit the problem this morning. I turned on the frontline sodera and saw no advertising packets. I pushed the button and advertisements started again immediately. This indicates to me that the bluetooth stack and bluetooth modules aren’t in a bad state when advertisements fail to start.
Is this a known issue and is there a work-around?
