Lost packet on RX (Central->Device)

RE: Lost packet on RX (Central->Device)

Kenneth — Tue, 08 Jun 2021 19:12:34 GMT

There are message sequence charts for both server and client in the softdevice specifications:

GATT server:
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s140.api.v7.2.0/group___b_l_e___g_a_t_t_s___m_s_c.html

GATT client:
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s140.api.v7.2.0/group___b_l_e___g_a_t_t_c___m_s_c.html

Kenneth

RE: Lost packet on RX (Central->Device)

Moshe Baker — Tue, 08 Jun 2021 09:11:05 GMT

Hi Kenneth,

Update - after changing implementation on SPI bus handling from polling to interrupt-driven, still issue persists. We thought it might be related to a performance issue due to SPI handling.

the on_write() handle is as follow. you can see we check CRC and index as part of our protocol over the BLE write, and we get the index error here. I added logging in the blocks which are ot the main block to see if we get in there by mistake, but we don't.

Note: we are not using an OS. I thought of moving the BLE write handling to the main loop, but still, how will the Central be informed to "wait"?

Question: how can we use the BLE write-with-response? I think we might use this to have a belter ACK mechanism, on each BLE write packet.

Thanks!

static void on_write(ble_am_t *p_am, ble_evt_t const *p_ble_evt)
{
ble_gatts_evt_write_t const *p_evt_write = &p_ble_evt->evt.gatts_evt.params.write;
ble_am_evt_t event = {.p_am = p_am};
p_am->conn_handle = p_ble_evt->evt.gap_evt.conn_handle;

// INFO Handle CCCD write (subscribe) for data_out_handle
if ((p_evt_write->handle == p_am->data_out_handle.cccd_handle) && (p_evt_write->len == 2)) {
nrfx_atomic_u32_store(&m_index_tx, 0);
on_generic_sessions_cccd_write(p_am, p_evt_write, BLE_AM_EVENT_DATA_OUT_NOTIFICATION_STARTED,
BLE_AM_EVENT_DATA_OUT_NOTIFICATION_STOPPED, &m_notify.data_out);
NRF_LOG_INFO("here 1");

// INFO Handle write for data_in_handle
} else if ((p_evt_write->handle == p_am->data_in_handle.value_handle) && (p_evt_write->len > 0)) {

uint32_t rec_index = uint32_decode(p_evt_write->data);

if (rec_index != rx_index)
NRF_LOG_INFO("BLE index error! rec_index: %d, %d",rec_index, rx_index);

rx_index++;

uint32_t calc_crc = crc32_compute(p_evt_write->data, p_evt_write->len - sizeof(uint32_t), NULL);

uint32_t rec_crc = uint32_decode(p_evt_write->data + p_evt_write->len - sizeof(uint32_t));
if (rec_crc != calc_crc)
NRF_LOG_INFO("BLE CRC error! cal_crc: 0x%x, 0x%x",calc_crc,rec_crc);

event.type = BLE_AM_EVENT_DATA_IN_WRITE;
event.params.p_data = (uint8_t *)p_evt_write->data + sizeof(uint32_t);
event.params.data_len = p_evt_write->len - sizeof(uint32_t) - sizeof(uint32_t);
//ble_write_ev = event;
p_am->event_handler(&event, NULL);

} else {
NRF_LOG_INFO("here 2");
NRFX_LOG_WARNING("%s unknown CCCD (0x%x)", __func__, p_evt_write->handle);
}
}

RE: Lost packet on RX (Central->Device)

Kenneth — Thu, 03 Jun 2021 11:15:31 GMT

I think you just need to look at the handling of BLE_GATTS_EVT_WRITE events, maybe add some debug information to see it it's possible you receive the BLE_GATTS_EVT_WRITE event but you somehow don't buffer/handle the received data in your application.

Kenneth

RE: Lost packet on RX (Central->Device)

Moshe Baker — Thu, 03 Jun 2021 10:37:20 GMT

It happens sometimes. The 840 is also doing SPI transfers using polling. No flash usage. Thanks!

RE: Lost packet on RX (Central->Device)

daviddedwin — Thu, 03 Jun 2021 06:18:35 GMT

The packet that was transmitted on the air at line number 201659 seems to have been acked by the peer. This means it was successfully received in a memory buffer on the nRF52840. This would typically mean that the code on the nRF52840 has to be reviewed.
Is this happening consistently ? Is there a lot of processing on the 840 ? Lot of flash usaga etc ?

RE: Lost packet on RX (Central->Device)

Moshe Baker — Thu, 03 Jun 2021 06:04:59 GMT

Please respond ASAP as this is at customer site. Thank you!