• State
  • Locked Locked
  • Replies 0 replies
  • Subscribers 51 subscribers
  • Views 167 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BOOST-CC2564MODA: CC2564MODA: Missing Disconnection Complete Event

Mohamed Nassar
Prodigy 10 points

Part Number: BOOST-CC2564MODA
Other Parts Discussed in Thread: CC2564MODA

Hardware/Software Configuration:

  • Module: CC2564MODA (CC2564B chip)
  • Service Pack: V1.8 (CC256XMSPV1.8)
  • Host MCU: TM4C123GXL (ARM Cortex-M4)
  • Bluetooth Stack: Bluetopia (TI official stack)
  • Transport: HCITR with cpHCILL_RTS_CTS flow control
  • Profile: SPP (Serial Port Profile) - Slave role
  • Power Mode: SNIFF enabled (power-saving mode)

Problem Description:

The CC2564MODA controller fails to generate Disconnection Complete Event When the remote device (Android/iOS phone) stops responding during an idle SPP connection in SNIFF mode. This occurs reliably after 4-5 minutes of idle time on a connected mobile device when the mobile device enters power-saving states (screen lock, app backgrounded, or the OS terminates Bluetooth background activity).

Expected Behavior:

  1. The remote device stops responding
  2. Link Supervision Timeout (LSTO) counter decrements to 0
  3. Controller generates Disconnection Complete Event with reason 0x08 (Connection Timeout)
  4. The host application receives a disconnect notification
  5. Clean disconnect and ready for a new connection

Actual Behavior:

  1. The remote device stops responding
  2. LSTO counter reaches 0
  3. No disconnect event generated
  4. Connection remains in "zombie" state:
    • Controller reports "connected."
    • Zero data throughput (Rx/Tx bps = 0)
    • The host believes the connection is active
  5. Eventually, all Bluetopia API calls return BTPS_ERROR_HCI_DRIVER_ERROR (-14)
  6. Only a hardware reset (nSHUTD pin toggle) can recover

I captured detailed logs using TI's Bluetooth Logger tool (an FTDI adapter connected to the TX_DBG pin at 115200 baud) during the failure scenario. 

Hardware reset on detection: - Toggle nSHUTD pin LOW → wait 100ms → HIGH - Reinitialize entire Bluetopia stack - Only method that recovers from zombie state

Note: Even `HCI_Reset()` commands fail once in this state (return error -14).

Why doesn't the disconnect event generate?

Is this a known bug in Service Pack V1.8? - If yes, is there a firmware patch available? - Are there workarounds at the controller configuration level? 

Is there a way to force disconnect detection? - HCI vendor commands to query link state? - Configuration to make LSTO more reliable? 

Attachments:

I have detailed TI Logger captures showing the complete failure sequence  SPPstress_issue_16Feb2025.txt Logger_logs.txt Main.c.txt SPPDemo.c.txt