Loadinginteractive807

• Cc2540 Hid
• Driver Ti Cc2540 Usb Cdc Update
• Driver Ti Cc2540 Usb Cdc Driver
• Cc2540 Driver Arduino

• 3Analysis
• 4Protocol
  • 4.2Reading BLE frames

The CC2540 USB Dongle is a complete example of how to use the USB enabled Bluetooth Low Energy (BLE) Wireless MCU. The reference design can be used to enable Bluetooth Smart and Internet of Things applications on any system that contains a USB host. The CC2540 USB Evaluation Module Kit contains one CC2540 Bluetooth low energy USB Dongle. The dongle can be used to enable Bluetooth low energy on your PC. It can also be used as a packet sniffer for analyzing the BLE protocol and for software and system level debugging (use the free tool SmartRF Packet Sniffer ). SERVICE = 'TI USB CDC Driver'. DESCCC2538 = 'TI CC2538 USB CDC Serial Port' DESCCC2540 = 'TI CC2540 USB CDC Serial Port' DESCCC2544 = 'TI CC2544 USB CDC Serial. It also, on my Windows 8 laptop, causes my USB keyboard to 'lose' some keystrokes. I sniffed some of the Bluetooth traffic using a TI CC2540 dongle and they have a proprietary protocol on top of.

Status

At this point (2017-05-09), the status is:

• it is pretty clear which commands the default sniffer firmware understands
• I wrote a little test program to dump raw BLE frames
• there is no plugin for WireShark yet

Introduction

This page is about the CC2540 bluetooth low-energy sniffer dongle and getting it to work with Linux.A nice end result could be that it becomes possible to sniff directly in WireShark with this dongle.

I have such a 'WeBee' dongle that can be found for about E15,- on websites like Aliexpress.

It's supposedly a CC2540 (or compatible) dongle, the USB id is 0451:16b3.

Interesting links:

Analysis

USB descriptor

When plugging this stick into a Linux machine, you can see it uses only one bulk endpoint.

Reading the identification from the stick with the 0xC0 command, results in the following 8-byte response

You can recognise the 2540 type number in there.

USB logs from Windows

This USB device does actually work with Windows:

I've captured a log of the communication over USB while the BLE is capturing bluetooth traffic from some iBeacon, using USB pcap.

In the logs, I cannot see any firmware blobs being downloaded to the stick.Probably the stick comes with a pre-loaded firmware of itself to do the BLE sniffing.

The USB control transfer request codes seem to match up with the code in https://github.com/christianpanton/ccsniffer/blob/master/ccsniffer.py

• 0xC0, GET_IDENT: returns some kind of identifier
• 0xC5, SET_POWER
• 0xC6, GET_POWER
• 0xC9, no idea, this appears in my USB logs but I can't find it in the python code
• 0xD0, START
• 0xD1, STOP
• 0xD2, SET CHAN

Protocol

In the windows sniffer software, it seems there are only two things communicated:

• towards the stick: which radio channel to sniff, and some other radio settings
• from the stick: raw sniffed BLE frames

Configuring the radio

This appears to be done using USB control transfers.

Cc2540 Hid

The following requests are sent:

Request type 0x40 is a vendor-specific device request from host-to-device.Request type 0xC0 is a vendor-specific device request from device-to-host.

Reading BLE frames

This appears to be done using USB bulk input transfers.

I can see a lot of similarities between the USB log and the BLE sniffer log.

Each frame starts with a byte indicating the type of frame, following by two bytes indicating the length of the rest of the frame (encoded as little endian).

data frames

The bulk USB data starts off with two bytes indicating the length of the rest of the data.

In the example image on the right:

• 00: 0 means this is a data frame
• 31 00: length of rest of frame encoded in little endian = 49 bytes decimal
• 39 04 29 54: part of the time stamp
• 2c d6 be ..: data frame contents

unknown frames (tick or 'alive'?)

The stick also returns 4-byte frames, alternating between

and

Interpretation:

• 01: 1 means this is a frame of type 1
• 01 00: length of the rest of the frame encoded in little endian = 1 byte
• 40 or C0: unknown data byte

Software

Preliminary code can be found athttps://github.com/bertrik/cc2540

It connects to the dongle and dumps raw USB packets to stdout.

This software requires libusb-1.0-dev

NOTICE: The Processors Wiki will End-of-Life on January 15, 2021. It is recommended to download any files or other content you may need that are hosted on processors.wiki.ti.com. The site is now set to read only.

Bluetooth Low Energy Wiki Main Page

This page describes some common configurations when using a CC254x in combination with an external MCU.

Overview[edit]

Network Processor[edit]

The HostTestRelease project (included with standard BLE SDK) is the standard BLE Network Processor application. It can be loaded on the CC2540 or CC2541, with the any of the following used as a network processor interface:

1. UART
2. SPI
3. USB CDC virtual UART (CC2540 only)

More information on the HostTestRelease project can be found in the CC254x BLE Software Developer's Guide (http://www.ti.com/lit/pdf/swru271). An overview of the HCI command protocol can be found in the TI BLE Vendor Specific HCI Guide, which is linked from the Windows Start Menu after you have installed the SDK.

For applications which only act as a GATT client and do not need to act as a GATT server, this is an ideal choice.

Network Processor GATT_DB_OFF_CHIP[edit]

The HostTestRelease project has an option that can be enabled by including the preprocessor define 'GATT_DB_OFF_CHIP' to the project configuration (under compiler settings). By adding this define, the network processor will be built such that any GATT services are maintained by the external MCU. This includes handling of all peer GATT requests to read, write, and discover services and characteristics.

This option provides for maximum flexibility of the GATT server by the MCU; however the code required on the external MCU is fairly complex.

More information on this type of setup can be found here: http://processors.wiki.ti.com/index.php/LPRF_BLE_NPGATT

Network Processor Custom[edit]

Rather than using GATT_DB_OFF_CHIP, another possibility is to manually add your GATT profiles to the HostTestRelease project, and rebuild the project with the services integrated into the network processor. This reduces the complexity of the external MCU code; however it requires the ability to add custom commands to the network processor in order to allow the external MCU to manage the data in the GATT services.

More information on this type of setup can be found here: http://processors.wiki.ti.com/index.php/BLE_HostTest_Add_Cmds

Stand Alone App with Serial Interface[edit]

Instead of using the HostTestRelease network processor project, another option is to take one of the existing single-chip projects included in the BLE SDK (e.g SimpleBLEPeripheral, HeartRate, RunningSensor, etc...) and modify it to include a 'UART bridge' or a 'SPI bridge', giving the external MCU the ability to communicate with the CC254x.

In addition to creating the brige using the HAL UART or HAL SPI drivers, a communication protocol must be established, allowing the external MCU to send commands to the CC254x (e.g. start advertising, send notification, etc...). It also must allow the CC254x to send event to the external MCU when specific actions occur (e.g. connection established, connection terminated, etc...). For many applications this protocol can be very simple and just consist of a few key commands and events.

Driver Ti Cc2540 Usb Cdc Update

More information on this type of setup can be found here: http://processors.wiki.ti.com/index.php/SimpleBLEPeripheral_SerialInterface

Other UART Configurations[edit]

See the following wiki page for all 4 UART configuations: http://processors.wiki.ti.com/index.php/All_4_uart_configs

Driver Ti Cc2540 Usb Cdc Driver

Cc2540 Driver Arduino