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.

[Sigurd]

jkim said:

We can change the logic regarding the APP_ERROR_CHECK implementation to not to generate exception on NRF_ERROR_BUSY and allow retry logic to work.

 Yes, this is the correct way to handle this. Take a look at how this is handled in e.g. components\ble\nrf_ble_gatt\nrf_ble_gatt.c (att_mtu_exchange_pending/att_mtu_exchange_requested)

jkim said:

In tx_buf_alloc, calling ser_hal_transport_tx_pkt_alloc returns err_code of NRF_ERROR_NO_MEM

 Hmm, so it's stuck in this loop? or does it exit the loop after a while?

static void tx_buf_alloc(uint8_t * * p_data, uint16_t * p_len)
{
    uint32_t err_code;

    do
    {
        err_code = ser_sd_transport_tx_alloc(p_data, p_len);
    }
    while (err_code != NRF_SUCCESS);
    *p_data[0] = SER_PKT_TYPE_CMD;
    *p_len    -= 1;
}

 

[jkim]

Yes, when I get NRF_ERROR_NO_MEM from tx_buf_alloc, calling ser_hal_transport_tx_pkt_alloc, it is stuck in this loop.  Since there are so many inconsistent behavior with this implementation, we have decided to try to use Nordic version of serialization only (and not use our version of serialization).  Once we get the two PCA10040 boards and try the Nordic example with iOS and Android, I will update our findings.  I will be out of office for several days, so I will probably have update late next week.  In the meantime, if you can keep this open that would be great.

[jkim]

Finally had chance to use two PCA10040 boards with Android as BLE Central.  Using the ser_s132_spi example from HRS, I was able to get the MTU size of 247 to work without any issues.  This confirms that the Nordic version of the serialization code supports MTU greater than 23.  Unfortunately, this means that our implementation of the serialization on STM32 board has issues.  We will use the Nordic example code and compare with our implementation to see what the difference is that is causing the issue.  We can close this post.

[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.