CC2640: CC2640频繁连接断开问题，重新烧录固件有时好，有时不行，但是行了一定可以。不行肯定就不行。

Li Allen

Part Number: CC2640

我目前在基于CC2640F128做一个蓝牙遥控器项目，一个模块做主机，一个做从机。经常有这种现象。原先两个设备正常烧录可以正常配对和绑定，也可以正常通信。但是如果将从设备重新烧录固件，一模一样的固件。出现二者不断连接，又断开。提示REASON 22的错误。并且两个设备重新断电重启都没有用。然后将主机或者从机重新烧录或者随便改一点无关的代码，重新烧录就又大概率的OK了。这种原因大概什么呢？由于这种现象很随机，并且，一模一样的固件，或者固件稍微改点又行了。但过一会重新烧一下又不行了。

部分参数设置如下：

// Maximum number of scan responses
#define DEFAULT_MAX_SCAN_RES 8

// Scan duration in ms
#define DEFAULT_SCAN_DURATION 4000

// How often to perform periodic event (in msec)
#define SBP_PERIODIC_EVT_PERIOD 500
// Discovery mode (limited, general, all)
#define DEFAULT_DISCOVERY_MODE DEVDISC_MODE_ALL

// TRUE to use active scan
#define DEFAULT_DISCOVERY_ACTIVE_SCAN TRUE

// TRUE to use white list during discovery
#define DEFAULT_DISCOVERY_WHITE_LIST FALSE

// TRUE to use high scan duty cycle when creating link
#define DEFAULT_LINK_HIGH_DUTY_CYCLE FALSE

// TRUE to use white list when creating link
#define DEFAULT_LINK_WHITE_LIST FALSE

// Default RSSI polling period in ms
#define DEFAULT_RSSI_PERIOD 1000

// Whether to enable automatic parameter update request when a connection is
// formed
#define DEFAULT_ENABLE_UPDATE_REQUEST GAPCENTRALROLE_PARAM_UPDATE_REQ_AUTO_ACCEPT

// Minimum connection interval (units of 1.25ms) if automatic parameter update
// request is enabled
#define DEFAULT_UPDATE_MIN_CONN_INTERVAL 400

// Maximum connection interval (units of 1.25ms) if automatic parameter update
// request is enabled
#define DEFAULT_UPDATE_MAX_CONN_INTERVAL 1200

// Slave latency to use if automatic parameter update request is enabled
#define DEFAULT_UPDATE_SLAVE_LATENCY 0

// Supervision timeout value (units of 10ms) if automatic parameter update
// request is enabled
#define DEFAULT_UPDATE_CONN_TIMEOUT 600

// Default passcode
#define DEFAULT_PASSCODE 19655

// Default GAP pairing mode
#define DEFAULT_PAIRING_MODE GAPBOND_PAIRING_MODE_INITIATE

// Default MITM mode (TRUE to require passcode or OOB when pairing)
#define DEFAULT_MITM_MODE TRUE

// Default bonding mode, TRUE to bond
#define DEFAULT_BONDING_MODE TRUE

// Default GAP bonding I/O capabilities
#define DEFAULT_IO_CAPABILITIES GAPBOND_IO_CAP_DISPLAY_ONLY

// Default service discovery timer delay in ms
#define DEFAULT_SVC_DISCOVERY_DELAY 1000

// TRUE to filter discovery results on desired service UUID
#define DEFAULT_DEV_DISC_BY_SVC_UUID TRUE

// Length of bd addr as a string
#define B_ADDR_STR_LEN 15

// Task configuration
#define SBC_TASK_PRIORITY 1

#ifndef SBC_TASK_STACK_SIZE
#define SBC_TASK_STACK_SIZE 864
#endif

1 年多前

0 Yolande Wang 1 年多前

TI__Genius 13330 points

您好，

您看到提示REASON 22的错误是在LOG日志中吗，首先得知道REASON 22错误的具体描述，您看看代码里对于REASON 22的定义。

0 Yolande Wang 1 年多前

TI__Genius 13330 points

错误代码REASON 22可能与连接问题有关，通常表示连接失败或中断。

在解决这个问题时，您可以尝试以下步骤：

1.清除设备的旧状态，包括配对信息和连接信息。

2.确保固件的一致性，不要在重新烧录时引入不必要的变化。

3.检查电源供应和复位操作，确保正确执行。

4.调试设备的连接问题，查看是否有错误日志或更详细的错误信息供参考。

0 Li Allen 1 年多前回复 Yolande Wang

Prodigy 70 points

case GAP_LINK_TERMINATED_EVENT:
{
state = BLE_STATE_IDLE;
connHandle = GAP_CONNHANDLE_INIT;
discState = BLE_DISC_STATE_IDLE;
charHdl = 0;
procedureInProgress = FALSE;
//uint8_t macBuf[6] = {0xB5,0xEE,0x6F,0x71,0x77,0x60};

// Cancel RSSI reads
SimpleBLECentral_CancelRssi(pEvent->linkTerminate.connectionHandle);

Display_print0(dispHandle, 2, 0, "Disconnected");
Display_print1(dispHandle, 3, 0, "Reason: %d", pEvent->linkTerminate.reason);
Display_clearLine(dispHandle, 4);

reason 22里面的22是从官方SDK里面获取的。另外配对banding成功后，是不是主机从机都会将banding信息写入Flash中？然后从机重新烧录时候，丢失这些信息，但是主机有配对信息，从而出现此种现象？

但是，有时候，我主机从机都重新烧录固件。好像也会继续弹出Disconnected。