I have run into a most interesting problem. If I have two connections active to two peripherals, in my case cc2540 devices, the cc2564 behaves poorly if both connections use the same connection interval. It only reads 1 packet from the peripheral per CI, even if the more data flag is set. If a CI is missed, or two packets need to be transmit in one CI the cc2540 starts queuing data and is never able to flush the queue. This results in all packets being delayed by (number of packets queued)*CI. When only 1 connection is active, or if the CIs are different for the two connections this does not happen.
If you use a slightly different connection interval, for example n=80 (100ms) and n=81 (101.25ms) the problem does not occur. This is less than ideal, and rather problematic if you use high frequency connection intervals.
To reproduce:
1. Have a single msp430+cc2564 running bluetopia 1.2.1 as provided from TI.
2. Start a BLE connection to a peripheral. I have a cc2540. Use a connection is say n = 80, 100ms.
3. Enable notifications for a characteristic. Mine runs at the same interval as the CI. So notifies every 100ms.
4. Verify it's arriving on time, and operating properly.
5. Start a BLE connection to a second peripheral. For example another cc2540 with the SAME connection interval as in #2. Once again n = 80, 100ms. The connection interval MUST be the same.
6. Both connections (but always the first) should now be in the buggy state. All packets coming the peripheral have MD = 1 and it never clears and the cc2564 never reads the 2nd packet. This means the cc2564 will have at least 1 packet queued if not more, and the device will never read more than 1 packet from the cc2540.
7. Disconnect the 2nd device, problem corrects itself.
Pictures taken while at step 6:
Sorry for the scaling Shows the TI packet sniffer at the moment of failure. You'll see packets before have MD = 0, then it goes to MD =1, yet only 1 packet is ever fetched. This condition persists until the 2nd device disconnects.
Trace showing the cc2540 power consumption during a connection interval up to step 5. You can see the current increase as the 2540 wakes up from sleep, goes into RX (lower consumption of the two peaks), then into TX (higher power use), prepares for sleep, then powers down. If multiple packets are sent in a CI you can see the RX and TX sections repeated.
During step 6. The red arrow points at the cc2540 waiting to RX the next packet from the cc2564, yet no packet is sent and no TX is made, ever. The cc2540 now starts queuing packets, delaying all data. it doesn't have much queue space and will eventually fail.
Work around, use a different CI for the two connections. For example n=80 and n=79. Even n=80 and n=160 appears to work. But there should be no reason for this.
