CODE AND STORAGE OVERLAP while building firmware for NRF52

Got larger MTU also working with SDK15 and nrf52840 dongle and there is interesting situation regarding nordic uart. In SDK12 the BLE_NUS_MAX_DATA_LEN is defined to 20 here https://github.com/espruino/Espruino/blob/master/targetlibs/nrf5x_12/components/ble/ble_services/ble_nus/ble_nus.h#L73 no matter what MTU is at build or run time. So it needs change there. In SDK15 this is defined in same targetlibs/nrf5x_15/components/ble/ble_services/ble_nus/ble_nus.h to be (NRF_SDH_BLE_GATT_MAX_MTU_SIZE - OPCODE_LENGTH - HANDLE_LENGTH) so in my case it is 56 automatically. And so it seem to be working out of box with Android and also Chrome in Windows if larger MTU is negotiated (and in fact it is). However if MTU is not negotiated or is lower (it can be done in nrfconnect, MTU auto negotiation is configurable in settings so if disabled one can use request MTU connection menu item later) it breaks and espruino sends larger data than the other side can receive. So with SDK15 it is broken out of box in this case.

However regarding this NRF_BLE_GATT_EVT_ATT_MTU_UPDATED it looks like it is more complicated as this is part of gatt module that is not linked to Espruino and in sdk12 is experimental and that event is there from SDK13 anyway. in sdk 12 it is here https://github.com/espruino/Espruino/blob/master/targetlibs/nrf5x_12/components/ble/nrf_ble_gatt/nrf_ble_gatt.c So I guess similar MTU code can be part of ble_evt_handler near case BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST.

EDIT: got it working, addded m_peripheral_att_mtu_effective near m_peripheral_conn_handle and in BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST I remember p_ble_evt->evt.gatts_evt.params.exchange_mtu_request.client_rx_mtu and it seem to work. in nrfconnect I can use 'Request MTU' menu item and data received is splitted correctly by value I set there -3.

So I guess I will do PR with everything possibly tomorrow or over weekend.

Wow, thanks - this is great!

So with SDK15 it is broken out of box in this case.

Great :/ We're actually using SDK 15.0 at the moment. I wonder if it's worth moving to 15.3 as it may have fixed that. I can take a look at how much it breaks stuff?

I think it is espruino code that is broken, I have updated patch gist, the issue is here
https://gist.github.com/fanoush/74c17abed6cfc809d153d76b6752e1f1#file-espruino-configurable-mtu-diff-L136
maybe it is not correct to send always up to BLE_NUS_MAX_DATA_LEN which is just maximum for the buffer

EDIT:
BTW I kind of stress tested WebIDE, uploaded ~250KB binary file to storage and upload was still pretty slow (minutes) but then download/view was much faster - like 10-20 seconds. So I guess WebIDE writes in 20 byte chunks but then reading back via notification use larger blocks. Or maybe it was writing to the flash that is so slow.

I guess I will do PR with everything possibly tomorrow or over weekend.

It is up there https://github.com/espruino/Espruino/pull/1998

Took a bit more time, worked fine with phone and PC before but when testing between two espruino devices higher MTU was not negotiated as no side started the negotiation so I needed to add that too - when being central and connecting to peripheral MTU negotiation is started, and possibly also DLE is requested on softdevice >3 (as the sd_ble_gap_data_length_update method is not there in 3.0 for some reason even if DLE support should be there in 3.0)