hci_api_switch_to_tcu_mode() fails

We have a timeout for BLE advertising that will fire if the advertising callback does not get called within a certain window. When this happens, we issue a hardware reset to the PAN1026, reset the SDK, and reinitialize everything. This usually succeeds and allows us to proceed with our normal application. However, I am now seeing a failure in hci_api_switch_to_tcu_mode(). Down in hci_api_tc35661_update_firmware(), one of the calls to hci_api_execute_m2_set() fails.

Digging down into the check_m2() function, the parse_hci_m2_xet_event() fails. This function is failing due to the check on hci_api.c:158. The event->event_code is 0x10, not the expected 0xff. This happens consistently after repeated hardware resets of the PAN1026. However, it happens for different instances in the loop that calls hci_api_execute_m2_set(). I've seen it for patches[] array items 5, 6 and 9.

Does this have to do with the 5ms "maximum transmit interval between each byte" described in 4.1.3 of the PAN1026 application note (here)?

Do I need to pace byte transmission by 5ms? That is really slow. I'm running at the slowest rate (115200 baud), but that results in byte times of 86.8us (@10bits/byte). Or is this limit describing the time between UART packet transmissions (either HCI or TCU)?

Ah, this makes more sense then. It is very possible that we are having some sort of thread contention that is causing a delay in packet transmission. We use FreeRTOS and the uart_appplication_send_bytes() does not use DMA, only blocking-mode transmission. I will review our implementation to see if DMA, or at least interrupt-driven transmit, is feasible.