SmarRF开发板使用后会断开

我购买了两个CC2540的SmartRF开发板，但是我发现在我使用一段时间后，我手机端的APP就无法连接蓝牙了，具体表现是连接之后会自动断开，然后我把官方例程SimplePeripheral烧写进去之后一直是这种状态，手机一连接会快速切换到Connected状态，但是一闪后回到了Advertising状态。请问这个大概是什么造成的呢？我的开发板版本是SmartRF V5.1

Yue TANG：

是官方购买的吗? 似乎没有这个smartRf V5.1的型号?
可使用packet sniffer抓包来分析.

processors.wiki.ti.com/…/BLE_sniffer_guide

BLE sniffer guide
Bluetooth Low Energy Wiki Main Page

Contents
1 Introduction
2 Installation and setup, using a CC2540 USB dongle as sniffer hardware
3 Using the sniffer
3.1 Radio configuration pane
3.2 Address book
3.3 Display filter
3.3.1 Filter on Unique Advertiser
3.4 Timeline
4 Packet types
4.1 Advertisement packets
4.2 Scan request / response
4.3 Connection establishment
4.4 Empty connection events
4.5 Read request, read response
4.6 Write request, write response
Introduction
The TI Packet Sniffer can be used to look at everything that goes on between two BLE devices over the air, and is as such a good tool for debugging or just learning about Bluetooth Low Energy applications. The TI Packet Sniffer is limited to capturing BLE data and control PDUs that follow the Bluetooth 4.0 and 4.1 specification. The following Bluetooth 4.2 optional features cannot be fully captured / decoded with the TI Packet Sniffer:

LE Data Length Extension – The Link Layer control procedure to set/configure longer PDUs can be observed, but PDUs that exceed 27 bytes cannot be observed. Other PDUs that are up to 27 bytes can be observed even though both devices have negotiated support for extended packet lengths. Note that a PDU > 27 bytes will only be sent when the App/Host sends a larger PDU payload.
LE Secure Connections – The Secure Connection pairing key exchange can be observed but the subsequent decode requires supplying the Long Term Key (LTK)

Installation and setup, using a CC2540 USB dongle as sniffer hardware
Download and install the SmartRF Packet Sniffer from [1]
Using SmartRF Flash Programmer, program the CC2540 USB dongle with the image found in \program files\Texas Instruments\SmartRF Tools\Packet Sniffer\bin\general\firmware\sniffer_fw_cc2540_usb.hex after installation. The manual on how to use SmartRF Flash Programmer with the CC Debugger to program the USB dongle can be found here.

Using flash programmer
Start the sniffer, select Bluetooth Low Energy and press Start

Starting the sniffer in BLE mode

Using the sniffer
To start sniffing, select the now programmed USB dongle, and press the play button.

Starting packet aquisition
The received packets will be parsed according to the packet format laid out in the Bluetooth 4.0 Core Specification[2] Volume 6, Part B, chapters 2.1, 2.3 and 2.4.

Radio configuration pane

Radio configuration
In the radio configuration pane you can

Specify which initiator IEEE address' connection you want to follow in the case that there are multiple BLE devices active (red ring). Otherwise the first detected connection establishment will be followed. You will still see all advertisement data.
Specify which advertisement channel you want to listen to (yellow): 37 (default), 38, or 39.
Note: The Packet Sniffer can only monitor one Advertising channel. If the connection request is sent by the Master on one of the other two available Advertising channels, then the sniffer will not be able to monitor the connection. For testing purposes with a TI peripheral, you can use GAPRole_SetParameter() to set the GAPROLE_ADV_CHANNEL_MAP parameter to a specific Advertising channel, e.g., GAP_ADVCHAN_37, so the peripheral only uses Advertising chan 37. See the available channel defines in gap.h. For the peripheral based sample applications in the BLE-Stack SDK (e.g., Simple Peripheral, SensorTag, Heart Rate, etc.), this parameter can be adjusted in peripheral.c at the following location:// Initialize the Profile Advertising and Connection Parameters…gapRole_AdvChanMap = GAP_ADVCHAN_ALL;// Set gapRole_AdvChanMap to the desired Advertising channel: GAP_ADVCHAN_37, GAP_ADVCHAN_38 or GAP_ADVCHAN_39
This parameter should only be used in test conditions as it is recommended to always Advertise on all three channels in production firmware.

Address book
TODO

Display filter
Filter on Unique Advertiser
Choose "ADV_IND AdvA" and press button "First", then add the address where x is, so the line says ex. AA1=0x112233445566. Then press "Add" followed by "Apply filter".

Packet Sniffer Filtering Advertiser
You should now only see advertiser with address 0x112233445566.
Timeline
TODO

Packet types
According to the state the device is in, different communication channels are applicable.

Advertising channel: 37 (2402MHz), 38 (2426 MHz) and 39 (2480 MHz)
Data channel: 0-36 (2404-2478 MHz) excluding (2426 MHz)
The advertising channel and data channel allow different Protocol Data Unit (PDU) types

PDU Types
Channel State PDU Type Explanation Core spec chapter
Advertising Advertising ADV_IND Connectable undirected advertising event. Contains AdvA and AdvData. 6.B.2.3.1.1 // 6.B.4.4.2.3 // 3.C.11 // 3.C.18.1 (payload)
ADV_DIRECT_IND Connectable directed advertising event. Contains AdvA and InitA 6.B.2.3.1.2 // 6.B.4.4.2.4
ADV_NOCONN_IND Broadcast. Contains AdvA and AdvData 6.B.2.3.1.3 // 6.B.4.4.2.6
ADV_SCAN_IND Connectable directed advertising event. Scannable. 6.B.2.3.1.4 // 6.B.4.4.2.5
Scanning ADV_SCAN_REQ Request for more information from LL in scanning state. ScanA, AdvA. 6.B.2.3.2.1 // 6.B.4.4.2.5
Advertising ADV_SCAN_RSP Response. 6.B.2.3.2.2 // 6.B.4.4.3.2
Initiating CONNECT_REQ Sent by initiator to establish a connection 6.B.2.3.3.1 // 6.B.4.4.4
Data Data LLID field is 1 or 2. Empty PDUs allow the slave to respond with any PDU. General data 6.B.2.4 // 6.B.4.5
Control LLID field is 3. PDU can not be emtpy Control data, see core spec 6.B.2.4.2 // 6.B.4.5
Advertisement packets
You will immediately start receiving captured advertisement packets, given that a peripheral is advertising. Fields 1,2,3,4 and 9,10,11 are common to all captured packets.
Using capt adv.png
Explanation for advertisement packet fields.
Field # Source Explanation Core spec chapter
1 Sniffer Packet number as logged by the sniffer
2 Capture device Time in microseconds since last packet was received and absolute time
3 Capture device Radio channel data was captured on 6.B.1.4.1
4 Air Bluetooth spec specified address for advertising and scan response 6.B.2.1.2
5 Air Type of advertisement packet 6.B.2.3
6 Air Header 6.B.2.3
7 Air Advertiser IEEE address 6.B.2.3
8 Air Advertisement data. In this example it's capabilities and three UUIDs the device provides. 6.B.2.3 / 3.C.11 / 3.C.18.1
9 Air Precalculated CRC checksum 6.B.2.1.4
10 Capture device Received signal strength indicator.
11 Capture device Field Control Sequence. If OK, the checksum is correct
The advertisement fields are further explained in 6.B.2.3 on page 2202 of the BT core spec.

Scan request / response
Scan request and response are two other types specified in 6.B.2.3, and look like the image below in the sniffer. The example below is of Active scan, and a sequence diagram is found in 6.D.4.2.
Using scan req.png
Here we can see that immediately following an advertisement indication (366µs), in the same advertisement event when the peripheral goes into RX mode, another device sends a scan request, which is then immediately answered by the peripheral device. The scan response in this instance is "Keyfobdemo"
Connection establishment
Connection establishment is initiated by the initiator (sic) on the peripheral RX slot of an advertisement event. The message format of the connection request is described in 6.B.2.3.3 in the Bluetooth core spec[3], and a message sequence diagram can be found in 6.D.5.1.
Using conn est.png
Here we see that Bluetooth LE connection establishment is pretty fast. Packet #185 shows an advertisement event peripheral TX slot, #186 shows connection request in the peripheral RX slot in the same event. Now the link is established. This is followed 20ms later by the first Central device initiated connection event's TX slot in #187, followed by a peripheral answer in #188 in the same connection event.

Empty connection events
After connection establishment we are in the connected state as defined by 6.B.4.5 in the BT Core spec. The data header is defined in 6.B.2.4 and is summarized below.
Using empty conn ev.png
Data header
Field Long name Explanation Core spec chapter
LLID Link Layer ID 0x1 = Data PDU; continued fragment or emtpy, 0x2 Data PDU Start of fragmented data or complete message, 0x3 Control PDU. 6.B.2.4 / 6.B.4.5
NESN Next expected sequence number 1-bit, used with SN for ack/nack 6.B.2.4 / 6.B.4.5.9
SN Sequence number 1-bit, used with NESN for ack/nack 6.B.2.4 / 6.B.4.5.9
MD More Data Used to indicate whether more data is coming. See table in spec. 6.B.4.5.6
PDU Length Length of payload + MIC in octets. PDU Length is maximum 27 octets. MIC 4 octets if present. 6.B.2.4
In this example we can see that the central device has SN = NESN indicating new data, and the peripheral device responds with ACK (SN!=NESN because it expects next packet).

Read request, read response
TODO

Write request, write response
TODO

Susan Yang：

请问您用的什么手机端APP？建议您抓包分析一下