[PATCH 0/1] Make initialization work for newer versions of TI CC2564

[PATCH 0/1] Make initialization work for newer versions of TI CC2564

[Michael Hunold]

My company recently released a new evaluation kit for the Panasonic PAN1326C2 Bluetooth module which is based on the revision B of the CC2564C chipset ("C2") from Texas Instruments.

This evaluation kit has a built-in USB-to-serial adapter, which makes it easy to attach it to any Linux-bases system and add Bluetooth functionality to it.

The CC2564 family is very well supported by BlueZ for years now, however this variant of the chipset does not work out-of-the-box.

You are probably well aware that these devices require a so-called initscript to be uploaded using vendor-specific HCI commands. For this "hciattach" has the special "texas" parameter and the necessary code for this special handling is in bluez/tools/hciattach_ti.c

CC2464C revision B requires the TIInit_6.12.26.bts initscript which can be obtained from https://git.ti.com/cgit/ti-bt/service-packs/tree/initscripts and has to be stored at /lib/firmware/ti-connectivity/ Usually you use something like hciattach -n /dev/ttyUSB0 texas 115200 in order to initialize a CC2564-based to be used in conjunction with BlueZ.

This works fine for earlier variants of CC2564, but not with CC2564C revision B. The initialization procedure seems to start, but stops at a certain point and the following error message is shown:

> Cannot send hci command to socket: Connection timed out

It seems that this problem is already known in the community for a long time, because it is described in the following thread in the Texas Instruments Bluetooth forum: https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/375766/can-t-init-device-cc2564b

It boils down to call to hci_send_req() in the function brf_send_command_socket() in bluez/tools/hciattach_ti.c.

> if (hci_send_req(fd, &rq, 15) < 0) {
>	perror("Cannot send hci command to socket");
>	return -1;
> }

The number 15 is a timeout value in milliseconds that in the end is passed down to a call to poll() on the file descriptor for the serial device.

I traced all the calls to brf_send_command_socket() and matched them with the commands that are included in the initscript.

The initial upload of some big vendor-specific data using the vendor-specific Send_HCI_VS_Write_Memory_Block command is working fine. Later in the script two calls to Send_HCI_VS_Read_Modify_Write_Hardware_Register() are done and it is always the second call that times out.

As described in the forum thread it seems that the CC2564C revision B (and already some earlier variants) take more than 15 milliseconds to complete these vendor-specific commands.

I verified that the solution to increase the timeout time from 15ms to something bigger actually works. By trial-and-error I could find out that starting with 20ms everything starts working fine again.

The original code was added approx. 15 years ago with the following commit: https://github.com/bluez/bluez/commit/14f84d602a7584f0805c93ae9ad1bd26e2387f6d

I think there is no way to find out today why 15 milliseconds were chosen as a timeout value at that time. From the way I understand the code it should not matter if a (way) higher timeout value is used here. If the low-level HCI command is successful it will return as quickly as possible and if there is an error, it will timeout no matter what.

So my suggestion is to increase the timeout value to something reasonable like 100ms instead.

I am aware that this patch is for the hciattach tool which is already deprecated and is not built by default any more. However, hciattach is the only tool to start and initialize the CC2564 series correctly under Linux and I guess it is still used by the people that use the CC2564 device under Linux.

Michael Hunold (1):
  tools/hciattach: Increase timeout for TI-specific initialization

 tools/hciattach_ti.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.34.1

[PATCH 1/1] tools/hciattach: Increase timeout for TI-specific initialization

[Michael Hunold]

The call to hci_send_req() in the function brf_send_command_socket() in
bluez/tools/hciattach_ti.c uses a timeout value of 15 milliseconds which
seems to be too short for newer variants of the CC2564 chipset, for
example the CC2564C revision B.

During initialization of these newer variants the initialization always
stops at a certain point during the processing of the device-specific
init script.

Increasing this value makes everything work again for the CC2564C
revision B.

Signed-off-by: Michael Hunold <michael.hunold@eu.panasonic.com>
---
 tools/hciattach_ti.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hciattach_ti.c b/tools/hciattach_ti.c
index 24efceaa1..918db868b 100644
--- a/tools/hciattach_ti.c
+++ b/tools/hciattach_ti.c
@@ -241,7 +241,7 @@ static int brf_send_command_socket(int fd, struct bts_action_send *send_action)
 	rq.rparam = response;
 	rq.rlen   = sizeof(response);
 
-	if (hci_send_req(fd, &rq, 15) < 0) {
+	if (hci_send_req(fd, &rq, 100) < 0) {
 		perror("Cannot send hci command to socket");
 		return -1;
 	}
-- 
2.34.1

RE: Make initialization work for newer versions of TI CC2564

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=793555

---Test result---

Test Summary:
CheckPatch                    PASS      0.45 seconds
GitLint                       PASS      0.31 seconds
BuildEll                      PASS      35.11 seconds
BluezMake                     PASS      1198.01 seconds
MakeCheck                     PASS      13.54 seconds
MakeDistcheck                 PASS      226.94 seconds
CheckValgrind                 PASS      348.68 seconds
CheckSmatch                   PASS      476.52 seconds
bluezmakeextell               PASS      150.97 seconds
IncrementalBuild              PASS      1084.78 seconds
ScanBuild                     PASS      1491.80 seconds



---
Regards,
Linux Bluetooth