[EXT_EP-9893] L2CAP recombination failing in some cases when data length update combines with L2CAP packet Created: 25/Jun/20 Updated: 02/Jul/24 |
|
Status: | Accepted |
Project: | Embedded Software & Tools |
Component/s: | None |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Bug | Priority: | Medium |
Reporter: | TI User | Assignee: | TI User |
Resolution: | Unresolved | Votes: | 0 |
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Product: | SimpleLink CC2640R2 SDK BLE Stack |
Internal ID: | BLESTACK-3934 |
Found In Release: | BLE Stack 3.2.0 |
Fix In Release: | BLE Stack 3.2.x |
Affected Platform/Device: | CC2640R2 |
Description |
Git/Installer Release Version: simplelink_cc2640r2_sdk_2_20_00_30_eng Application: BTool v1.42.08 (in BLE3 mode), simple_peripheral_oad_offchip ( FlashROM_unsecure configuration) Problem Reproducibility: 90% Problem Description: When using BTool v1.42.08 in BLE3 mode to perform an over the air download using unsecure off chip images, it appears that the two l2cap packets that are used to send the ATT Prepare Write request for a GATTWriteLong are not being recombined and are thus seen as garbage packets and not sent to ATT. This leads to an ATT timeout. I have only been able to replicate this with OAD using the steps below. It appears to have something to do with the timing of the data length update request, potentially as it collides with the GATTWriteLong. I've tried hostTest to hostTest and replicated the exact scenario (data length response from slave occurs on same connection interval as ATT prepare write request from master) but don't see the bug. Steps to re-create problem:
|