Using BlueZ 5.2 HciTool to Communicate with CC2540

Brian Cook

Other Parts Discussed in Thread: CC2540

I am using the TI BLE HCI Vendor Specific HCI Guide to attempt communication with the CC2540 using the BlueZ 5.2 hcitool cmd. I can successfully connect and disconnect from the CC2540.

Hcitool cmd 0x08 0x0d 0x04 0x00 0x04 0x00 0x00 0x00 0xfd 0x0f 0xa0 0xe5 0xc5 0x78 0x00 0x0f 0x00 0x0f 0x00 0x00 0x00 0x80 0x0c 0x01 0x00 0x01 0x00 provides a connection to 78:c5:e5:a0:0f:fd and returns a connection handle of 1025.

Hcitool cmd 0x01 0x06 0x01 0x04 0x16 disconnects from connection handle 1025.

I now want to read the GATT_DEVICE_NAME_UUID contents at handle 0x0003. I interpret this to be either a GATT_ReadCharValue (0xFD8A) or a ATT_ReadReq (0xFD0A). The request parameters format includes just the UUID handle value (0x0003). My translation of this command for hcitool is as follows:

GATT_ReadCharValue: hcitool cmd 0x3f 0x018a 0x03 0x00 (or)

ATT_ReadReq: hcitool cmd 0x3f 0x10a 0x03 0x00

Neither of these commands retrieve the device name. Neither is the request picked up by the Smart RF Sniffer which means the message format is probably wrong. When I use btool, the retrieval works correctly with the following information:

[319] : <Tx> - 11:19:58.992

-Type : 0x01 (Command)

-Opcode : 0xFD8A (GATT_ReadCharValue)

-Data Length : 0x04 (4) byte(s)

ConnHandle : 0x0000 (0)

Handle : 0x0003 (3)

Dump(Tx):

01 8A FD 04 00 00 03 00

------------------------------------------------------------------------------------------------------------------------

[320] : <Rx> - 11:19:59.038

-Type : 0x04 (Event)

-EventCode : 0xFF (HCI_LE_ExtEvent)

-Data Length : 0x06 (6) bytes(s)

Event : 0x067F (GAP_HCI_ExtentionCommandStatus)

Status : 0x00 (Success)

OpCode : 0xFD8A (GATT_ReadCharValue)

DataLength : 0x00 (0)

Dump(Rx):

04 FF 06 7F 06 00 8A FD 00

------------------------------------------------------------------------------------------------------------------------

[321] : <Rx> - 11:19:59.163

-Type : 0x04 (Event)

-EventCode : 0xFF (HCI_LE_ExtEvent)

-Data Length : 0x17 (23) bytes(s)

Event : 0x050B (ATT_ReadRsp)

Status : 0x00 (Success)

ConnHandle : 0x0000 (0)

PduLen : 0x11 (17)

Value : 48 65 61 72 74 20 52 61 74 65 20 53 65 6E 73 6F 72

Dump(Rx):

04 FF 17 0B 05 00 00 00 11 48 65 61 72 74 20 52

61 74 65 20 53 65 6E 73 6F 72

I assume my hcitool cmd format is incorrect. Can someone provides assistance so that I can correctly use the hcitool for communication with the cc2540 using BlueZ?

over 12 years ago

0 Sign Bit over 12 years ago

Expert 1570 points

I haven't tried BlueZ yet (it's on my TODO list) but I notice that some of the arguments to hcitool are 8 bit and some are 16 bit. Try using only 8 bit values, and use the buffer dump provided by BTool as an example.

0 Brian Cook over 12 years ago in reply to Sign Bit

Prodigy 120 points

I understand your suggestion. Unfortunately, a translation occurs between the "hcitool cmd ogf ocf <parameters>" command string and the btool buffer dump that prevents direct comparision . The buffer dump displays the opcode for the combined ogf/ocf, parameter length, and parameters. It would be nice if the TI BLE Vendor Specific HCI Reference Guide included an ocf column for the vendor specific commands. Also, a detailed parameter list description (as shown in the Bluetooth Core V4.0, Volume 2, Part E-Host Controller Interface Functional Specification) is missing for each vendor specific command. Is this missing information available from another source?

0 Sign Bit over 12 years ago in reply to Brian Cook

Expert 1570 points

Are you familiar enough with C and GDB? I would build BlueZ with debugging enabled then place a breakpoint after the buffer is assembled but before is sent out the wire. We know that BTool works (mostly, see the known write timeout but that is not fixed for 6 months now) - so we need to 'monkey see, monkey do' programming.

The documentation is sparse and bug reports or requests for help are not a priority for TI, so it's time to get dirty ;) But, in all fairness, I do appreciate the availability of tools such as BTool and HCI Tester - they are invaluable!

0 Janka Lon over 12 years ago

Prodigy 90 points

Hi,Brian.

I am also making some test on my CC2540USBDongle by using BlueZ.

And, I have follow the setup according to http://genuinepulse.blogspot.fi/search?q=cc2540

while he typed the #hciconfig -a . And the follow out come:

hci1: Type: BR/EDR Bus: UART

BD Address: 3C:2D:B7:84:0B:3B ACL MTU: 0:0 SCO MTU: 0:0

UP RUNNING

RX bytes: 271 acl:0 sco:0 events:19 errors:0

TX bytes: 121 acl:0 sco:0 commands:16 errors:0

Features: 0x00 0x00 0x00 0x60 0x00 0x00 0x00 0x00

Packet type: DM1 DH1 HV1

Link policy:

Link mode: SLAVE ACCEPT

By, unfortunately, It don't get the "UP RUNNING".....I get the Down.......

Then ,i typed #sudo hciconfig hci0 up

I get "time out"

Could you please tell me that what other thing i should??

Sorry for my poor english.

Thanks in advancd.

0 Sign Bit over 12 years ago in reply to Janka Lon

Expert 1570 points

Hi Janka,

What version of BlueZ are you using? With the version included in the Raspberry Pi distribution, I get occasional timeouts and not everything is working, but I know I need to build the latest version from source.

0 Janka Lon over 12 years ago in reply to Sign Bit

Prodigy 90 points

Hi, Sign.

I switch to use the BlueZ5.4 on kernel v3.9.

Luckily, the CC2540Dongle can be the UP State.

However, It still not to lecc(connect).

I have try the python tool which can be download on the ble-wiki-ti. It also can not connect,just lescan can work.

0 Brian Cook over 12 years ago in reply to Sign Bit

Prodigy 120 points

I was not aware of HCI Tester. This may be the tool I need to answer my question. I'll need to experiment with it.

Bluetooth®︎

Bluetooth forum

Using BlueZ 5.2 HciTool to Communicate with CC2540