LMP Response Timeout (0x22) do to an incomple LL_LENGTH_REQ!

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
RaMe_1910901
Level 1
Level 1

Central/Master: Application built on CySmart 1.3, as well as the CySmart application, on a CY5677 BLE 4.2 dongle, Windows 10

Peripheral/Server: nRF52833-DK

40s after Central connects to the peripheral, the peripheral disconnects due to a LMP Response Timeout (0x22). My understanding is that this is a 40s timeout. In the attached Ellisis Bluetooth Analyzer trace (LMPTimeout.btt), we see that the peripheral resumed advertising at 48.702 455 000. Going back 40s, to 8.700 884 500, we have an incomplete LLCP Data Length Update sequence; the nRF sent a LL_LENGTH_REQ to the pSoC4. The pSoC4 never responds, and 40s latter the nRF disconnects and resumes advertising.

This happens 100% of the time! We use the CySmart/Dongle combination in our automated testing.

Given that I see it with the CySmart 1.3 application, I assume it's a BLE stack issue. However, is there a CySmart API callback I should implement to force the LL_LENGTH_REQ response?

Thanks,

Randy

0 Likes
1 Solution

Hi Randy,

Yes. PSoC 4 BLE supports Bluetooth 4.2 spec which has a provision for Data Length Extension. You can either set this directly in the component GUI as shown below:

DLE.PNG

Or you can also use the API CyBle_GapSetDataLength() present in page number 106 of the BLE component datasheet obtained from the link below:

https://www.cypress.com/file/464666/download

For more information please refer the application note:

https://www.cypress.com/documentation/application-notes/an99209-psoc-4-ble-and-proc-ble-bluetooth-le...

Thanks and regards

Ganesh

View solution in original post

0 Likes
7 Replies
RaMe_1910901
Level 1
Level 1

For got to add that the dongle is running C:\Program Files (x86)\Cypress\CySmart\1.3\dongle\CY5677\BLE_4_2_Dongle_CySmart_256K_psoc.hex

0 Likes

Hi Randy,

1. Are you seeing this issues on nRF52833-DK device only or on Cypress PSoC BLE devices also? If you have not tested it, can you please test once? You can test with PSoC 4 BLE Find me code example.

2. Thank you for attaching the ellysis air log. If possible, can you please attach CySmart app log also?

Thanks

Ganesh

0 Likes
lock attach
Attachments are accessible only for community members.

(1) I'm only seeing this when Cypress is Central and nRF52833-DK is the peripheral. We commonly use Cypress PSoC4 as the peripheral with no issue.

(2) Attached.

0 Likes

Hi Randy,

I think the logs attached do not match with the statements in the doc. Please confirm that the logs are correct as this capture is only for 11 seconds, but the doc mentions nRF restarting ADV after 40 s?

Thanks

Ganesh

0 Likes
lock attach
Attachments are accessible only for community members.

My apologies for taking so long to respond, I've been fighting another fire that consumed all of my spare cycles.

The CySmart App shows a different issue; a quick disconnect; 0x2a - BLE_HCI_DIFFERNT_TRANSACTION_COLLISION. I pair on the first connection attempt, but following attempts disconnect almost imminently:

[00:54:21.050,781] <debug> nrf_ble_gatt: Requesting to update ATT MTU to 128 bytes on connection 0x0.

[00:54:21.050,781] <debug> nrf_ble_gatt: Updating data length to 132 on connection 0x0.

[00:54:21.050,781] <info> app: BLE_GAP_EVT_CONNECTED

[00:54:21.050,781] <debug> app:    conn_handle 0

[00:54:21.050,781] <debug> app:    resolved  0

[00:54:21.050,781] <debug> app:    addr_type 0

[00:54:21.050,781] <debug> app:    peer_addr 0x00-A0-50-D0-61-51

[00:54:21.050,781] <debug> app:    min_conn_interval 7 * 1.25ms

[00:54:21.050,781] <debug> app:    max_conn_interval 7 * 1.25ms

[00:54:21.050,781] <debug> app:    slave_latency    0

[00:54:21.050,781] <debug> app:    conn_sup_timeout  10 * 10ms

[00:54:21.052,734] <info> app: PM_EVT_CONN_SEC_PARAMS_REQ

[00:54:21.071,289] <debug> nrf_ble_gatt: ATT MTU updated to 128 bytes on connection 0x0 (response).

[00:54:21.071,289] <info> app: Data len is set to 0x7D(125)

[00:54:21.071,289] <info> app: ATT MTU exchange completed. central 128 peripheral 128

[00:54:21.071,289] <debug> app: BLE_GATTC_EVT_EXCHANGE_MTU_RSP

[00:54:21.098,632] <info> app: BLE_GAP_EVT_DISCONNECTED, reason 0x2A

I've attached new logs and sniffer capture in CySmart2.zip.

When using our own SonicBlue application, a C# Windows application that uses the CySmart Library, we see the LMP Response Timeout 40s after connecting.

We doesn't seem to have any issues when connecting from SonicBlue(CySmart), CySmart 1.3 to a PSoC4 peripheral.

0 Likes

Does the PSoC4 support the LE Data Packet Length Extension (DLE?) If so, how do we enabled it via the CySmart API?

We (Torin) introduced a workaround where we don't change our GAPP Data Length to prevent the LLCP update.

0 Likes

Hi Randy,

Yes. PSoC 4 BLE supports Bluetooth 4.2 spec which has a provision for Data Length Extension. You can either set this directly in the component GUI as shown below:

DLE.PNG

Or you can also use the API CyBle_GapSetDataLength() present in page number 106 of the BLE component datasheet obtained from the link below:

https://www.cypress.com/file/464666/download

For more information please refer the application note:

https://www.cypress.com/documentation/application-notes/an99209-psoc-4-ble-and-proc-ble-bluetooth-le...

Thanks and regards

Ganesh

0 Likes