CC2745R10-Q1: CC2745R10-Q1 – GATT timeout even on SINGLE write (any size) when using invokeFunction + queue send in changeCB

Part Number: CC2745R10-Q1

Dear TI Team,

Device : CC2745R10-Q1

SDK : SimpleLink Low Power F3 SDK 9.14.00.xx (BLE5-Stack)

Problem Description

We are observing consistent BLE connection drops with GATT timeout (reason 0x08 or 0x13) immediately after a single GATT Write from the central device.
The issue occurs only when we forward the write event to a FreeRTOS queue. If we avoid sending to the queue, the connection remains stable.

Payload size does not matter (1 byte, 40 bytes, etc.) and the write is not repeated or spammed.

Event Flow

1. Phone writes to characteristic

2. BLE2Service_writeAttrCB() → invokes BLE2Service_callback(paramID)

3. BLE2Service_callback() performs:

   • ICall_malloc()

   • BleAppUtil_invokeFunction()

4. BleAppUtil task context runs → BLE2Service_invokeFromFWContext() → dispatches to registered change callback

5. Inside our change callback (BLEService2_changeCB), we currently do:

memcpy();
xQueueSendToBack(myQueue, &msg, 0);

xQueueSendToBack() always returns pdPASS.

Observation

Even though queue send is immediate, total time spent inside the invoked callback is still a few milliseconds (due to malloc, memcpy, and debug logging).

We now understand that this callback executes in time-critical BleAppUtil context, and any delay here appears to interfere with BLE stack timing, resulting in the peer disconnecting with a GATT timeout.

Question

What is the current official recommended way (2025, BLE5-Stack 9.x) to safely forward a GATT write event (or just the paramID) from the write callback to my own FreeRTOS application task when I need to do memory allocation / logging / parsing?

I just need the exact few lines that are considered 100 % safe on CC2745R10-Q1 for production/Q1 projects.

Thank you!

Best regards,

Parish Jain