1. rf_device中的RF_START_BOUND_EVENT绑定事件，绑定时，会读取存过的对端地址，会造成无法绑定新设备

   

2. rf_device 如果执行绑定时，将对端地址设置为0，此时会和之前绑定过的主机进行绑定，就算主机退出绑定了
   

主机上电绑定超时后，设备进行绑定操作，主机会重复进入rfRoleBoundProcess回调

https://www.cnblogs.com/azou/category/2391224.html，此博客有做注释讲解。

其中，

1、device端一旦配对过就会将对方地址存入flash中，如果要解绑，需要在对应dataflash位置清除该地址数据，也就是调用DeleteBoundInfo接口，至于ID号是哪个，可以在绑定回调中拿到。

2、Host端的绑定做法是，上电后的前三秒允许任意设备配对，如果在三秒内没有连接到设备，超过三秒后则只会回连上次配对过的设备。

1、拿一个device和 Host1 绑定，绑定成功后，此时device和Host1能够正常通讯，把Host1关闭[不上电]。

2、然后在用这个device和Host2绑定，此时device和Host2能够正常通讯，然后把Host1上电

3、此时在用device执行绑定操作，他会在Host1 和 Host2之前来回切换绑定

device删除绑定信息后，对应peer mac信息为全0，之后在host1和host2都上电的情况下，device被谁绑定是随机的，取决于device先收到来自于哪个host的绑定通讯包。

但是device一旦绑定上，并存有一个host的绑定信息，另一个host是永远都不能再与这个device通讯（除非在device端删除绑定信息）。

至于你所说的在host1和host2之间来回绑定，也许是哪边调用有误，可以这样调试看看，检查下绑定信息有没有成功清除：

->在device初次上电时，会首先进入到RF_START_BOUND_EVENT这个任务中，关注下bound.PeerInfo数组并打印出来，查看存储的是全0，还是两个host其中的一个，bound结构体传入底层后，如果mac地址非0，则只会接收与peer mac匹配的连接请求包。

一个device和一个host执行完绑定，且绑定成功，此时device在继续执行绑定，这个host还是继续执行绑定。

host已经执行完绑定且成功了，应该断电重启之后才会继续执行绑定吧

抱歉，您表述的方式，我这边不太能了解具体的问题点。

无论何时，只要发生断开，那么host一定是处于查询附近是否有设备能够连接的状态(一直在发送配对请求包)。

给出的demo中，Host程序在首次上电运行RF_Init()函数时，可以看到启动了两个任务，立即启动的任务是绑定任意设备，另一个三秒后执行的任务是指回连。

问题:主机在进行回连的时候，会和设备进行绑定

只要host端存有你这个device的地址信息或者绑定信息为空，且device端存储的对端地址被清除了，那么在host发出配对请求包后，device的RF底层会收到这包数据，并进入RF绑定回调完成绑定。

1、device和host绑定成功后

2、host进入了回连状态，然后在将device设置为绑定状态

然后，host还是会和device绑定

您描述的这个现象是符合当前程序逻辑的，

因为device解除绑定后，意味着peer info信息被清空，且在回连阶段会使用接入地址接收等待Host的配对信息，而Host端由于发生断连，也会立即使用接入地址进行寻找与自己当前dataflash中存储的MAC地址吻合的Device设备，因此在Device刚进入绑定状态就会被Host所连上。

如果在Device解除绑定时不再想让当前这个Host所连接，可在Device端解除绑定并且启动RF_START_BOUND_EVENT任务时，

其中，可做这样的处理：

        uint8_t MacAddr[6];

        GetMACAddress( MacAddr );//获取自身芯片MACADDR信息

        MacAddr[3]++;//对6字节MACADDR进行处理，使其不要与上一次发送的配对包中的自身地址相同即可，此处是一个演示

        tmos_memcpy(bound.OwnInfo, MacAddr, 6);//将新地址设备存入bound结构体，在下方存入底层后，Host再收到配对包后解析会发现这个device会是一个新设备，与上次配对的Device信息不符，因此就不会主动回连

        ...................

        RFBound_StartDevice( &bound );

应该区分下回连和绑定的逻辑，主机回连的时候，如果device在进行绑定，主机不应该响应device的绑定。库中多增加一个标志，用于区分回连和绑定，这样应该就不会有问题。

配对和回连都是我们定义的行为，需要我们在应用层处理，底层是不区分这些的。

应用层不好获取状态

typedef struct

{

    bStatus_t status; //!< Status for the connection

    /* SUCESS

     * bleTimeout:When the connection times out, it automatically switches to the bindable state

     * FAILURE:If the device binding fails on the device side, the application layer needs to restart the binding */

    uint8_t role;     //!< the role of the binding

    uint8_t devId;    //!< The ID number of the binding

    uint8_t devType;  //!< The device type of the binding

    uint8_t periTime; //!< reserved

    uint8_t hop;      //!< Frequency hopping mode

    uint8_t PeerInfo[6]; //!< Information about the peer device

} staBound_t;

这个是绑定的数据结构，没有能够判断绑定和回连的状态。

绑定和回连都需要应用层判断，底层只会根据应用层传入的SpeedList结构体进行连接，不区分是配对新设备，还是回连旧设备。

Host只负责连接跟SpeedList.peerInfo相吻合的deivce设备，当Host发出配对包后被符合的device收到且回复应答后(底层处理)，双方都会立即进入rfRoleBoundProcess告知应用层连接成功。

所以您不应该关注这个绑定连接回调任务，应该着重看RFBound_SetSpeedType( &gSpeedList_t );中的gSpeedList_t变量，其中peerInfo[6]数组是人为定义并传输至底层的，因此传入的这个数组如果为空，对于我们来说就是绑定任意设备的行为，如果这个数组不为空，那么就是回连某一个特定设备。