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.

BTPS_CONFIGURATION_HCI_SYNCHRONOUS_WAIT_TIMEOUT_MS - any way to reduce this?

My application has some sensitive watchdogs that need to report in every 1/10th of a second, or at the very least, once every 11 seconds. The Bluetopia stack library appears to have this 5000 ms wait timeout burned into it (TM4C build) and if the Bluetooth chip locks up in the middle of being used, it causes some 5 second delays to happen. A lot of my code calls multiple things in a row that may end up trying to hit up the chip for some HCI command.

Can this value be reduced, or is there some way to kick it out of that loop, or can I possibly work around it somehow?

  • Hi,

    It's not possible to modify this. But it's not expected that the chip locks up while being used. Five seconds is about the right time for the stack to wait for a command complete from the chip.

    Can you please share the logger logs where it shows the chip locks up? Which service pack version are you using? Do you see the problem with the latest SP (v 1.4) ? It's available at: processors.wiki.ti.com/.../CC256x_Downloads

    Regards,
    Gigi Joseph.
  • Yes, I am using SP 1.4. Using the NoOS variant of the stack, in a thread pretty much dedicated to running Bluetopia.

    Attached is the logger log.logger.zip

    The setup: 2 phones and 2 headsets connected to the CC256x. Streaming audio from one of the phones.

    For the first 10 minutes of the log, I'm repeatedly turning off the headsets and turning them back on, and there are no problems. The headsets reconnect and there is no problem receiving the incoming stream or sending commands to the chip. (Note: I have a periodic check every 5 seconds, HCI_Read_Scan_Enable, to check to see if the chip is still responding)

    At line 107692, I turn on the A3DP streams and continue the process of turning off the headsets and turning them back on. The headsets reconnect, the A3DP streams start, the incoming stream is fine, and communication with the chip is fine.

    So after about 7 minutes of this working fine, the lockup occurs. Here's what went down:

    I shut off the headsets

    At line 157689, I get notification that the AUD stream has closed, so I signal A3DP stop stream and A3DP close stream. The other one disconnects closely thereafter. Everything seems fine so far. I turn the headsets back on

    At line 161661, one of the headset requests the connection, it's accepted, and at 163535 I open the A3DP stream to this headset, and everything is fine.

    The other headset does not request a connection to me as it normally does when it starts up, so I go into my menu to manually reconnect it. (i.e. the CC256x calling out to it, rather than the headset calling to the CC256x)

    At line 173866, the connection is requested. At 174214, the last periodic HCI_Read_Scan_Enable I got. At 174868, the connection complete event comes in, and at 174888, a max slots change event. That is the last event I receive from the stack. The log ends at 174889, I don't see anything in the logger after this happens until I reboot, there are never any errors put in the log when this particular condition occurs.

    A couple seconds after the lockup, my system attempts HCI_Read_Scan_Enable, then the stack waits 5 seconds and returns error -14 BTPS_ERROR_HCI_DRIVER_ERROR. I try to tear everything down, uninitialize all profiles and BSC_Shutdown, but so many things that I need to do to properly unregister things will attempt to communicate with the chip, each of them lock up for 5 seconds again.

    It's sitting there repeatedly calling HCITR_COMProcess in a busy loop for that 5 seconds each time, so I've tweaked the function to yield to other threads if there are 0 bytes available in the read buffer when this is called. But since the Bluetopia thread does not finish within 11 seconds due to several 5 second waits in a row, my watchdog is triggered and the whole system resets hard.

    The issue of locking up does not appear to be isolated to when A3DP is used, but it does seem to aggravate the issue. (I could swear I've had this happen without an A3DP stream in use, but as is often the case, I could not reproduce that particular scenario while observing it with the logger)

  • Hi,

    It looks like you haven't enabled the Logger traces and only enabled the LMP Viewer.
    Can you enable both and take a new log? The option is available in "View->Settings".

    Regards,
    Gigi Joseph.
  • Both traces were enabled. I updated to the latest .ili and .xml files from the site for init file 6.7.16 (linked to from the logger user guide wiki page), and made sure to run HCI communication at 921600 bps (normally I run 2 mbit but forgot to do so for the previous trace) and captured a new trace.

    It still doesn't look like it contains any more data than the other one did. Do I need a different service pack that enables more debug logging? I note that I have to go to View -> Show All Items before I see some of the log entries.

    0131.logger.zip

    In the case of this trace, the issue occurs after item 145104. The lockup causes a watchdog reset in my application and everything is restarted starting at 145472

  • Hi,

    Thanks, we'll take a look at the logs and get back to you.

    Regards,
    Gigi Joseph.
  • Hi,

    Can you please take the logger logs with this attached version?
    It's a version with lots of debug traces enabled.


    test_version-debug.bts

    Regards,
    Gigi Joseph.

  • log with debug base patch.zip

    Here you go. The log contains a few reconnect attempts where the lockup does not occur, in the first nearly 8 minutes. The lockup occurs after the connection that is created at log number 187667.

    Thanks!