Moddable Nimble MTU size increase issue

[jainilsshah]

I am using moddable Nimble in one project. I want to transfer 256/512 bytes over BLE between BLE server (custom esp32s3 hardware) and nrf connect mobile application (BLE client).

In esp32s3 firmware, I have created one characteristic with write and notify properties. I have increased MTU size from nrf connect mobile application by using "requesting MTU" feature and set size to 256. On esp32s3 firmware, I used "CONFIG_BT_NIMBLE_ATT_PREFERRED_MTU=256" to increase MTU size to 256. On nrf connect application log, I see message "new MTU set to: 256". After increasing MTU on nrf connect, if I try to write on characteristic it is not successful and mobile app disconnects BLE connection after some seconds (may be due to timeout or not able to send packet over BLE). App log shows - Error 133(0x85): GATT ERROR and Error 22(0x16): GATT CONN TERMINATE LOCAL HOST.

Is there any other change or configurations required on esp32s3 firmware side to increase MTU size. Please help me suggesting required changes to fix this issue.

[phoddie]

On esp32s3 firmware, I used "CONFIG_BT_NIMBLE_ATT_PREFERRED_MTU=256" to increase MTU size to 256

FWIW – that is already the default:

moddable/build/devices/esp32/xsProj-esp32s3/sdkconfig.defaults

Line 208 in 298fe72

CONFIG_BT_NIMBLE_ATT_PREFERRED_MTU=256

From your explanation, there is no obvious mistake. It looks like the MTU size has been successfully set based on the nRF Connect output you report. If you don't set the MTU size, are you able to write a characteristic?

[phoddie]

Good to see the BLE_GAP_EVENT_MTU being logged. The event is just a notification to report the new MTU size. No special handling is required.

It would be interesting to see that value, to confirm it matches what you set using the mobile app. You can do that by implementing the onMTUExchanged callback function, which is passed the new MTU size:

class YOURCLASS extends BLEServer {
	// ...
	onMTUExchanged(size) {
		trace(`MTU size is now ${size}\n`);
	}
	// ...
}

[jainilsshah]

Thanks for the continued response.

I have added mentioned callback and print the MTU size. Whenever issue (not able to write on characteristic after MTU size update from nef connect mobile app) occurs, I am getting incorrect MTU size (0) on esp32s3.

I have debugged it further and enabled some more prints. I got incorrect MTU size sometimes in nimble_gap_event() callback when received BLE_GAP_EVENT_MTU event. Further this callback passes this to mtuExchangedEvent() and getting event->mtu.value value as 0 inside this API. I don't know whether nrf connect mobile app sends wrong MTU size or esp32s3 receives wrong MTU size. Is there any way to identifies this as I don't have BLE sniffer to check this. nimble_gap_event() is the first place at esp32s3 source code where BLE server receives MTU size change request from BLE client, correct? Is there anyway to check anything further at esp32s3?
File.zip

I am not using default esp32s3 sdkconfig default file what you have mentioned (moddable/build/devices/esp32/xsProj-esp32s3/sdkconfig.defaults. Please find attached my project sdkconfig file.

[phoddie]

I have increased MTU size from nrf connect mobile application by using "requesting MTU" feature and set size to 256

I have a question. Where is the "requesting MTU" feature in the nRF Connect mobile app? I don't see it in the iOS nRF Connect app.

[phoddie]

FWIW – I ran the uart-server example to experiment with this.

• Used ESP32-S3
• Latest Moddable SDK (4.6.0)
• ESP-IDF 5.1.2 (recommended)
• Ran nRF Connect and LightBlue mobile apps on iOS
• On connect, MTU size is automatically bumped up to 256 (add on onMTUExchanged() to the example to see that)
• Able to write strings of over 100 bytes to the "Rx" characteristic
• Able to receive strings of over 100 bytes from the "Tx" characteristic

This all seems as expected. What is different about your testbed?

[jainilsshah]

"Reqeusting MTU" feature is not available and not required for iOS nrf connect app as iOS BLE stack automatically sends MTU change request while connection establishment that is why MTU size is updated automatically at your end.

I am doing testing with android nrf connect BLE app and it provides features to update MTU size after connection.

I found this while searching for same issue. Please find below link. Can you please guide whether it is required or not?
espressif/esp-idf#9627

I checked in my Moddable BLE implementation that it doesn't contain this changes.

[phoddie]

I am doing testing with android nrf connect BLE app and it provides features to update MTU size after connection.

I see. It is new information that you are using Android. Perhaps NimBLE does not support updating the MTU size after the connection is established?

I found this while searching for same issue. Please find below link. Can you please guide whether it is required or not?
espressif/esp-idf#9627

I checked in my Moddable BLE implementation that it doesn't contain this changes.

The link you shared does not propose a specific change. In fact, the developer who opened the issue noted, "In fact, I can not find the functions for increasing LL packet size...".

[jainilsshah]

Thanks for the update. I really appreciate your help and dedicated support, looking forward for the same in future.

I found this demo example inside esp-idf. Please find this demo (esp idf\examples\bluetooth\nimble\throughput_app\bleprph_throughput) and it has below implementation regarding LL packet size increase.

#define LL_PACKET_LENGTH  251

static int blecent_gap_event(struct ble_gap_event *event, void *arg)
{
switch (event->type) {
        case BLE_GAP_EVENT_CONNECT:
        /* A new connection was established or a connection attempt failed. */
        if (event->connect.status == 0) {
            /* Connection successfully established. */
            /* XXX Set packet length in controller for better throughput */
            ESP_LOGI(tag, "Connection established ");
            rc = ble_hs_hci_util_set_data_len(event->connect.conn_handle,
                                              LL_PACKET_LENGTH, LL_PACKET_TIME);
    }
}

I think we need to perform this change according to this link - espressif/esp-idf#12789

Please help me to conclude regarding MTU size and changes required to achieve it. Please confirm should I move ahead with this changes or not. I can perform this changes at my end and let you know the result.

[phoddie]

You can easily give that a try. The BLE_GAP_EVENT_CONNECT for the server is here:

moddable/modules/network/ble/nimble/modBLEServer.c

Lines 779 to 791 in 3d6d0f8

	case BLE_GAP_EVENT_CONNECT:
	if (event->connect.status == 0) {
	if (0 == ble_gap_conn_find(event->connect.conn_handle, &desc)) {
	if (gBLE->mitm || gBLE->encryption)
	ble_gap_security_initiate(desc.conn_handle);
	modMessagePostToMachine(gBLE->the, (uint8_t*)&desc, sizeof(desc), connectEvent, NULL);
	goto bail;
	}
	}
	c_memset(&desc, 0, sizeof(desc));
	desc.conn_handle = -1;
	modMessagePostToMachine(gBLE->the, (uint8_t*)&desc, sizeof(desc), connectEvent, NULL);
	break;

After line 789, you can add:

            #define LL_PACKET_TIME            2120
            #define LL_PACKET_LENGTH          251
            ble_hs_hci_util_set_data_len(event->connect.conn_handle, LL_PACKET_LENGTH, LL_PACKET_TIME);

I look forward to hearing the results of your test. Good luck!

[jainilsshah]

I have tried with mentioned changes, but not able to solve this issue.

Perhaps NimBLE does not support updating the MTU size after the connection is established?
I am able to update MTU size once connection is established from nrf connect app. So, at very first time connection is established I am able to update MTU size and able to write characteristic (no issue observed), but if I perform connection-disconnection cycle and establish connection again at that time issue is observed - not able to write characteristic.

[jainilsshah]

Is it restriction in nimble that it allows only once to update MTU after esp32s3 boots up? Please check regarding this and let me know.

[phoddie]

Is it restriction in nimble that it allows only once to update MTU after esp32s3 boots up? Please check regarding this and let me know.

This is a question about the NimBLE implementation on ESP-IDF. That implementation is provided by Espressif. This question is most appropriately asked of Espressif on their repo.

Of course, if there is something we can do in the Moddable SDK to support this feature, we are open to considering that. However, at this time there is no indication that the problem is caused by how the Moddable SDK uses NimBLE.

[jainilsshah]

Can you please do one favor for me? Can you please run uart-server demo that you have run earlier with android nrf connect app with below steps?

• Used ESP32-S3
• Latest Moddable SDK (4.6.0)
• ESP-IDF 5.1.2 (recommended)
• Connect ESP32-S3 with android nrf connect mobile app. Change MTU size from nrf connect mobile app to 256.
• Write on characteristic. It should work without any issue.
• Perform BLE disconnection.
• Connect ESP32-S3 with nrf connect mobile app again.
• Change MTU size to 256.
• Now, try to write on characteristic. Please check whether you are able to write on char successfully or not. I am facing issue in this step.
• On second time connection process onwards, I am not able to write on char after updating MTU size.

I am not using latest ESP-IDF and Moddable versions as old versions are already integrated in my project. So, Intention behind asking you for this testing is to check whether this scenario is working with latest ESP-IDF and Moddable version successfully or not. If this is working successfully then we can conclude that it may fix in newer versions and I may need to integrate new ESP-IDF and Moddable in my project.

Again, thanks for the efforts and appreciate your help and support here.

[jainilsshah]

@mkellner Is it possible for you to test the same with Moddable version 4.0 and ESP-IDF version 4.4 ?

[jainilsshah]

@mkellner I have done testing with your provided binaries and it is working as expected. No issue observed with it.

Can you please try to find information that Moddable version has fix this issue? I am using Moddable 4.0 and latest available is 4.6.0. So, it may be possible that it was fixed. If I find this info then it is too much helpful for me to conclude.

If possible please do testing with older Moddable version.

[phoddie]

I have done testing with your provided binaries and it is working as expected. No issue observed with it.

Excellent! You have a solution.

Can you please try to find information that Moddable version has fix this issue?

Your question presumes that the only place that the issue could have been solved Is in the Moddable SDK. But others have observed the same or similar issues without using the Moddable SDK. So, it appears at least possible that the issues is in the ESP-IDF.

Only one file related to NimBLE changed between Moddable SDK 4.0 and 4.6: modBLECommon.c. Those changes were part of moving to ESP-IDF 5. Perhaps you can run those changes on ESP-IDF 4.x. I don't know.

There were many BLE changes in the ESP-IDF between 4.4.3 (used in Moddable SDK 4.0) and 5.1.2 (used in Moddable SDK 4.6). That seems more likely to be the responsible for the improved behavior here.

Please let us know what you find. Thank you!

[jainilsshah]

Thanks for providing information.

I have checked by modifying modBLECommon.c file, but it doesn't resolve the issue.

Now, I have started looking into ESP-IDF version changes. Let me know if you have any comment on this.

[phoddie]

I have checked by modifying modBLECommon.c file, but it doesn't resolve the issue.

Good that you tried. That said, the changes didn't look likely to be relevant to the issue.

Now, I have started looking into ESP-IDF version changes. Let me know if you have any comment on this.

That seems like the right path. Good luck.

[phoddie]

Closing this out as it has gone dormant and the issue appears to be outside the scope of the Moddable SDK.