MAX MTU Size using Serialization SDK 17.0.2

[jkim]

We are using NRF52832 with STM32L4A6 using serialization.  We have the serialization working properly, but having an issue with the MAX MTU size.  We can set the NRF_SDH_BLE_GATT_MAX_MTU_SIZE between 23 to 48 and serialization works fine.  When we increase to 49 or later, the serialization hangs.  Further investigation shows that in the on_connected_evt method, calling sd_ble_gattc_exchange_mtu_request method ultimately calls the ser_phy_tx_pkt_send which checks for the mp_tx_buffer and this buffer pointer is not NULL.  Our guess is that previous serialization call did not complete properly (thus does not reset the mp_tx_buffer).  It seems very odd that changing the NRF_SDH_BLE_GATT_MAX_MTU_SIZE causes the serialization issue.

In the SDK17.0.2 example project, ble_peripheral | ble_app_hrs | pca10040 | SER_132_spi, we noticed that the NRF_SDH_BLE_GATT_MAX_MTU_SIZE is set to 23.  However, in the non serialized example of the ble peripheral, the NRF_SDH_BLE_GATT_MAX_MTU_SIZE is set to 247 and works properly.  The NRF_SDH_BLE_GAP_DATA_LENGTH is set to 27.

Has anyone had success setting the NRF_SDH_BLE_GATT_MAX_MTU_SIZE to larger than 48 using the serialization?  If so, what was the test setup and the values for the NRF_SDH_BLE_GATT_MAX_MTU_SIZE.

We are using SDK 17.0.2 with softdevice s132_nrf52_7.2.0 on PCA10040 as connectivity module.

[jkim]

Nordic is BLE Peripheral and communicating with iOS and Android as BLE Central.  iOS and Android both have the same issue.  I was trying to debug what was the previous serialization call was but it is really hard to debug it.  I can try to add some delay, but my guess is that it won't help.  I set a break point on on_connected_evt and step through the calls and and it hangs due to mp_tx_buffer not being NULL.  For NRF_SDH_BLE_GATT_MAX_MTU_SIZE of 23, it does not hang (mp_tx_buffer is NULL).  I see that pc-ble-driver example softdevice is not the same as what we are using s132_nrf52_7.2.0.  Not sure if I can use it as is.

We will be getting two PCA10040 soon, so I will use the examples from SDK 17.0.2 from ble_peripheral | ble_app_hrs | pca10040 | SER_132_spi and see if we can get NRF_SDH_BLE_GATT_MAX_MTU_SIZE larger than 23 consistently only using the Nordic code.  Has anyone already tried using SDK 17.0.2 using s132_nrf52_7.2.0 to see if serialization works for NRF_SDH_BLE_GATT_MAX_MTU_SIZE greater than 23?

[jkim]

Yes.  It does return NRF_ERROR_BUSY.  However, in the, APP_ERROR_CHECK(err_code), our implementation does not handle the NRF_ERROR_BUSY.  Also, ser_sd_transport_cmd_write does not appear to handle the retry.  Is this correct assessment?

uint32_t ser_sd_transport_cmd_write(const uint8_t * p_buffer,
uint16_t length,
ser_sd_transport_rsp_handler_t cmd_rsp_decode_callback)
{
uint32_t err_code = NRF_SUCCESS;

m_rsp_wait = true;
m_rsp_dec_handler = cmd_rsp_decode_callback;
err_code = ser_hal_transport_tx_pkt_send(p_buffer, length);
APP_ERROR_CHECK(err_code);

/* Execute callback for response decoding only if one was provided.*/
if ((err_code == NRF_SUCCESS) && cmd_rsp_decode_callback)
{
if (m_ot_rsp_wait_handler)
{
m_ot_rsp_wait_handler();
m_ot_rsp_wait_handler = NULL;
}

m_os_rsp_wait_handler();
err_code = m_return_value;
}
else
{
m_rsp_wait = false;
}

NRF_LOG_DEBUG("[SD_CALL]:%s, err_code= 0x%X", (uint32_t)ser_dbg_sd_call_str_get(p_buffer[1]), err_code);
return err_code;
}

[Gavin]

How many central link counts when you  setting the NRF_SDH_BLE_GATT_MAX_MTU_SIZE to 247 ?

[jkim]

We were able to resolve the issue.  The issue is the BLE event mailbox size (which is dependent on MAX_MTU_SIZE) was much larger than we thought.  we set the internal buffer which extracts from the BLE event mailbox to 512 (largest size for SPI), and no longer gets the stack corruption.  We can now set MAX_MTU_SIZE to 247 without any issues.  The Nordic implementation of the serialization works.  However, it is quite challenging to port it over to STM32 processor and requires a lot of effort on our side.