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.

CC2564MODA: HCI error

Part Number: CC2564MODA
Other Parts Discussed in Thread: CC2564

Tool/software:

I have CC2564MODA chip connected to a custom board running Linux with cip kernel 4.19 and BlueZ stack. The board communicates with PC application over Bluetooth using RFCOMM protocol.

Every time they start to exchange messages the communication stops after a few seconds. Logs captured at Bluetooth stack level revealed that the controller stops sending HCI messages to host and any HCI commands that host tries to send to controller end with timeout. That's why I think the problem is on controller side.

How can I see what is going on in the controller? Is there a way without tapping BT_DEBUGG pin as that would be challenging for me?

  • Hi,

    Other than the debug pin you could try to tap into the UART HCI lines and take logic analyzer traces and see the communication happening between the Controller and the host. Before that however, I would first check to see if you receive any error if you use bt monitor. in the terminal type

    btmon &

    If you cant find any solid reason why the device stops responding to the host, we will need to take FW logs using the bt_debug pin...

    Best,

    Rogelio

  • Hi Rogelio,

    I don't see any error when using btmon.

    Since my chip is on custom board and according to schematics only cts, rts, rxd, cxd, reset, shutdown, vdd_io, vdd_in pins are accessible I have to tap the UART HCI lines. 

    Would the bt_debug pin have provided more information than uart lines?

    Best regards,

    Stano

  • Hi Stano,

    Yes the BT_debug pin will print out FW logs that gives us a lot more information of whats happening internally in the chip. If the Chip is for some reason crashing or asserting it would tell us that information.

    Another test you could do is try running the bluetopia stack demos on your linux device (for example SPP) If you see the same behavior then it could be something going on with how the cc2564 is connected? What are you calling on bluez before the device stops responding, is the behavior repeatable or sporadic 

    Best,

    Rogelio