Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

'esp_ble_gatts_send_indicate' fails when 'value_len' is larger than 512 (IDFGH-14150) #14953

Open
3 tasks done
carlessole opened this issue Nov 28, 2024 · 5 comments
Open
3 tasks done

'esp_ble_gatts_send_indicate' fails when 'value_len' is larger than 512 (IDFGH-14150) #14953

carlessole opened this issue Nov 28, 2024 · 5 comments
Assignees
@esp-zhp
Labels
Status: In Progress Work is in progress Type: Bug bugs in IDF

Comments

@carlessole
Copy link

carlessole commented Nov 28, 2024 •
edited
Loading

Answers checklist.

  • I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
  • I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
  • I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.3

Espressif SoC revision.

ESP32

Operating System used.

Windows

How did you build your project?

Eclipse IDE

If you are using Windows, please specify command line type.

CMD

Development Kit.

Custom Board

Power Supply used.

USB

What is the expected behavior?

Hi,

We’ve encountered an issue when interacting over BLE with some Android devices, specifically Google Pixel and some Samsung Galaxy models.
The problem seems to be related to the MTU size of the Android device, which in these devices is set to 517 (instead of 512).
After reading the ESP-IDF BLE Documentation, it is said MTU=517 is supported:

By default, the MTU size of ESP32 Bluetooth LE is 23 bytes, and can be configured to reach 517 bytes.

Also see ESP_GATT_MAX_MTU_SIZE macro (=517).

What is the actual behavior?

The issue arises when in esp_ble_gatts_send_indicate the 'value_len' >= 512 (due to a resulting total MTU of 515 or higher, as 'ATT header (3 bytes)' is already considered as in ble_spp_server example)
Although esp_ble_gatts_send_indicate is returning 'ESP_OK' -> (ee 'Debug Logs' section)
Note also that setting the LOG verbosity to maximum 'ESP_LOG_VERBOSE' is not reporting any message that indicates that the function is having any error.

Please, see 'Debug Logs' section.

Steps to reproduce.

See 'What is the actual behavior?' section

Debug Logs.

  • MTU limited to 512: Works as expected: 3 BLE frames are received by Android Phone
(11:55:18.966) *****************************************
(11:55:18.966) 'ESP_GATTS_MTU_EVT':MTU_RECEIVED:517:LIMITED:512
(11:55:18.994) *****************************************
(11:55:21.930) *****************************************
(11:55:21.930) 'BLE PACKET TO SEND:1237
(11:55:21.930) *****************************************
(11:55:21.930) *****************************************
(11:55:21.945) 'MTU_USED:512
(11:55:21.945) *****************************************
(11:55:21.945) *****************************************
(11:55:21.945) 1561 | ble_spp_helper_write: 'esp_ble_gatts_send_indicate':FRAME:1/3:LEN:509:OK:ESP_OK
(11:55:21.959) *****************************************
(11:55:21.959) *****************************************
(11:55:21.959) 1561 | ble_spp_helper_write: 'esp_ble_gatts_send_indicate':FRAME:2/3:LEN:509:OK:ESP_OK
(11:55:21.976) *****************************************
(11:55:21.976) *****************************************
(11:55:21.976) 1592 | ble_spp_helper_write: 'esp_ble_gatts_send_indicate':FRAME:3/3:LEN:231:OK:ESP_OK
(11:55:21.976) *****************************************
  • MTU limited to 515: Still works: 3 BLE frames are received by Android Phone
(12:04:17.049) *****************************************
(12:04:17.049) 'ESP_GATTS_MTU_EVT':MTU_RECEIVED:517:LIMITED:515
(12:04:17.049) *****************************************
(12:04:18.514) *****************************************
(12:04:18.514) 'BLE PACKET TO SEND:1237
(12:04:18.514) *****************************************
(12:04:18.514) *****************************************
(12:04:18.514) 'MTU_USED:515
(12:04:18.514) *****************************************
(12:04:18.514) *****************************************
(12:04:18.514) 1561 | ble_spp_helper_write: 'esp_ble_gatts_send_indicate':FRAME:1/3:LEN:512:OK:ESP_OK
(12:04:18.514) *****************************************
(12:04:18.514) *****************************************
(12:04:18.514) 1561 | ble_spp_helper_write: 'esp_ble_gatts_send_indicate':FRAME:2/3:LEN:512:OK:ESP_OK
(12:04:18.546) *****************************************
(12:04:18.546) *****************************************
(12:04:18.546) 1592 | ble_spp_helper_write: 'esp_ble_gatts_send_indicate':FRAME:3/3:LEN:225:OK:ESP_OK
(12:04:18.546) *****************************************
  • MTU limited to 516: Already fails: Just last packet is received by Android Phone
(12:08:21.496) *****************************************
(12:08:21.496) 'ESP_GATTS_MTU_EVT':MTU_RECEIVED:517:LIMITED:516
(12:08:21.496) *****************************************
(12:08:23.049) *****************************************
(12:08:23.049) 'BLE PACKET TO SEND:1237
(12:08:23.049) *****************************************
(12:08:23.065) *****************************************
(12:08:23.065) 'MTU_USED:516
(12:08:23.065) *****************************************
(12:08:23.065) *****************************************
(12:08:23.065) 1561 | ble_spp_helper_write: 'esp_ble_gatts_send_indicate':FRAME:1/3:LEN:513:OK:ESP_OK
(12:08:23.080) *****************************************
(12:08:23.080) *****************************************
(12:08:23.080) 1561 | ble_spp_helper_write: 'esp_ble_gatts_send_indicate':FRAME:2/3:LEN:513:OK:ESP_OK
(12:08:23.096) *****************************************
(12:08:23.096) *****************************************
(12:08:23.096) 1592 | ble_spp_helper_write: 'esp_ble_gatts_send_indicate':FRAME:3/3:LEN:223:OK:ESP_OK
(12:08:23.112) *****************************************
  • No MTU limitations: Fails: Just last packet is received by Android Phone
(12:13:47.074) *****************************************
(12:13:47.074) 'ESP_GATTS_MTU_EVT':MTU_RECEIVED:517:LIMITED:517
(12:13:47.074) *****************************************
(12:13:49.795) *****************************************
(12:13:49.795) 'BLE PACKET TO SEND:1237
(12:13:49.810) *****************************************
(12:13:49.810) *****************************************
(12:13:49.810) 'MTU_USED:517
(12:13:49.810) *****************************************
(12:13:49.810) *****************************************
(12:13:49.829) 1561 | ble_spp_helper_write: 'esp_ble_gatts_send_indicate':FRAME:1/3:LEN:514:OK:ESP_OK
(12:13:49.829) *****************************************
(12:13:49.829) *****************************************
(12:13:49.845) 1561 | ble_spp_helper_write: 'esp_ble_gatts_send_indicate':FRAME:2/3:LEN:514:OK:ESP_OK
(12:13:49.845) *****************************************
(12:13:49.845) *****************************************
(12:13:49.859) 1592 | ble_spp_helper_write: 'esp_ble_gatts_send_indicate':FRAME:3/3:LEN:221:OK:ESP_OK
(12:13:49.859) *****************************************

More Information.

No response
@carlessole carlessole added the Type: Bug bugs in IDF label Nov 28, 2024
@github-actions github-actions bot changed the title 'esp_ble_gatts_send_indicate' fails when 'value_len' is larger than 512 'esp_ble_gatts_send_indicate' fails when 'value_len' is larger than 512 (IDFGH-14150) Nov 28, 2024
@espressif-bot espressif-bot added the Status: Opened Issue is new label Nov 28, 2024
@carlessole
Copy link
Author

Until now, I thought the problem was solely related to the negotiated MTU being 517 (which means a value_len in esp_ble_gatts_send_indicate larger than 512).
However, I tested with another Android device with an MTU of 517, and it works. Currently, the results are as follows:

  • Google Pixel 6 Pro: MTU 517 → Fails

  • Samsung Galaxy A15 5G: MTU 517 → Fails

  • OnePlus Nord 4: MTU 517 → Success

  • Any Android device with an MTU of 512 (or when the MTU size is limited to 512 by code) → Success on all devices.

@carlessole
Copy link
Author

I am also attaching screenshots from the BLE Android Serial Terminal:

Success Example: (MTU Limited to 512) 3 BLE frames are receive by Android device
image

Fail Example: (MTU is 517) Just last packet is received by Android device
image

@carlessole
Copy link
Author

There’s a "loose end" that I’m not entirely clear about, related to the ATT Header Size.
I’ve been assuming it’s a constant 3 bytes:

#define CUSTOM_MAX_MTU_SIZE      512 // See: https://github.com/espressif/esp-idf/issues/14953
#define ATT_HEADER_SIZE           3 // 'ATT Transmission Unit' headers -> Pending to find real documentation about this
#define MULTIPACKETS_HEADER_SIZE  4 // ##xy [x:total_num, y: current_num]
#define SPP_DATA_SIZE             (spp_mtu_size - ATT_HEADER_SIZE)
#define SPP_MULTIPACKET_DATA_SIZE (SPP_DATA_SIZE - MULTIPACKETS_HEADER_SIZE)

However, I found documentation suggesting that the ATT Header Size for Android can be up to 5 bytes:
MTU is set to 517 for the first GATT client requesting an MTU

Alternatively, limit your GATT characteristic writes based on the minimum between the known supported value of your peripheral and the received MTU change

  • A reminder that you should reduce 5 bytes from the supported size for the headers
  • For example: arrayMaxLength = min(SUPPORTED_MTU, GATT_MAX_ATTR_LEN(517)) - 5

Could it be that the ATT Header is defined by the GATT Client and that the server must adapt/replicate the same header when answering? And could this be the reason why it fails on certain devices, where the ATT Header is 5 bytes?

Is there any way in ESP-IDF to retrieve the ATT Header size from the client, so I don’t hardcode 3 bytes as a constant and instead dynamically adjust to the client’s header size?

@espressif-bot espressif-bot added Status: In Progress Work is in progress and removed Status: Opened Issue is new labels Dec 3, 2024
@esp-zhp
Copy link
Collaborator

esp-zhp commented Dec 3, 2024

@carlessole
could you revert 20a780d,and test again?

@esp-zhp
Copy link
Collaborator

esp-zhp commented Dec 10, 2024

@carlessole Any updates?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@esp-zhp esp-zhp

Labels
Status: In Progress Work is in progress Type: Bug bugs in IDF
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@carlessole @espressif-bot @esp-zhp