嗨对话框，
我正在开发一对BLE设备，两个服务器和从站，基于DA14580。在彼此连接之后，即使我留下这些处理器闲置（没有读/写/通知，否I2C，GPIO ...处于活动状态），但它们仍然断开随机连接。它看起来像链接层中的一个腐败，因为在断开连接后，它们无法再次重新连接。以下是我为此连接设置的参数以及一些Wireshark捕获。
msg->nb_peers = 1;
memcpy（（void *）和msg->对等体[0] .addr，（void *）peer_addr，bd_addr_len）;
msg->对等体[0] .addr_type = peer_addr_type;
msg->con_intv_max = 10;
msg->con_intv_min = 10;
msg->ce_len_max = 0x20;
msg->ce_len_min = 0x20;
msg->con_latency = 0;
msg->superv_to = 100;
msg->scan_interval = 0x180;
msg->scan_window = 0x160;
msg->op.code = GAPM_CONNECTION_DIRECT;
Wireshark捕获：
9796 61.273854000 Master Slave BLE Data 26 Empty Data PDU
9797 61.275295000从站主机BLE数据26空数据PDU
9798 61.286603000主从机BLE数据26空数据PDU
9799 61.287569000 Slave Master BLE Data 26 Empty Data PDU
9800 61.298855000 Master Slave BLE Data 26 Empty Data PDU
9801 61.299789000从站主机BLE数据26空数据PDU
9802年62.320227000 ab_mat5 BLE ADV 48 ADV_IND
9803 62.321788000 AB_MAT5 BLE ADV 48 ADV_IND
Server and client keep the connection for 60s and could not connect to each other anymore.
我仍然可以看到奴隶侧广告，但甚至使用iPhone使用LightBlue应用程序，我无法再连接到奴隶。
Wireshark捕获：
25 6.273182000 AB_MAT4 BLE ADV 48 ADV_IND
26 6.274736000 50:0b:f8:18:ac:29 80:ea:ca:00:00:41 BLE ADV 60 CONNECT_REQ
27 6.276461000 Master Slave BLE Data 26 Empty Data PDU
28 6.303327000 Master Slave BLE Data 26 Empty Data PDU
29 6.333342000 Master Slave BLE Data 26 Empty Data PDU
30 6.363329000 Master Slave BLE Data 26 Empty Data PDU
31 6.393384000 Master Slave BLE Data 26 Empty Data PDU
32 6.423327000 Master Slave BLE Data 26 Empty Data PDU
33 6.453367000 Master Slave BLE Data 26 Empty Data PDU
34 6.483385000 Master Slave BLE Data 26 Empty Data PDU
35 6.513421000 Master Slave BLE Data 26 Empty Data PDU
36 6.543378000 Master Slave BLE Data 26 Empty Data PDU
37 6.573448000 Master Slave BLE Data 26 Empty Data PDU
38 6.603361000主从机BLE数据26空数据PDU
39 6.633361000主从机BLE数据26空数据PDU
40 7.640482000 ab_mat4 BLE ADV 48 ADV_IND
41 7.642505000 ab_mat4 BLE ADV 48 ADV_IND
在此测试中，我将连接间隔设置为12.5 ms。在这种情况下，服务器和客户端将在60秒到45分钟后随机断开连接。
In my latter test, I change the connection interval to be 30ms. They could keep the connection much longer(more than 10 hours), but still they disconnect.
我想假设我在空闲状态下将处理器留下，一切都应该自动通过BLE堆栈处理并发送空以保持连接应与我的应用程序代码无关。此外，我在断开连接时没有任何应用活动。
Please help me to find the reason why the disconnect and how to improve the stability of the connection.
Thanks a lot.
一些更新，
从我的隔夜测试中，它看起来像BLE定时器无法适当地工作。
Firstly, it works okey for about 3 hours(probably more). We could see master sends an empty PDU to slave every 30ms as the value I set.
726216 10926.699285000 Master Slave BLE Data 26 Empty Data PDU
726217 10926.699861000 Slave Master BLE Data 26 Empty Data PDU
726218 10926.729275000 Master Slave BLE Data 26 Empty Data PDU
726219 10926.729815000 Slave Master BLE Data 26 Empty Data PDU
726220 10926.759274000主从机BLE数据26空数据PDU
726221 10926.760253000 Slave Master BLE Data 26 Empty Data PDU
726222 10926.789250000 Master Slave BLE Data 26 Empty Data PDU
726223 10926.790219000 Slave Master BLE Data 26 Empty Data PDU
726224 10926.818524000主从BLE数据26空数据PDU
I guess the sniffer lost one capture here..
726225 10926.848719000主从机BLE数据26空数据PDU
726226 10926.850223000 Slave Master BLE Data 26 Empty Data PDU
To some reason, I lost the capture for about 10 hours. Luckily, just before they disconnect, the sniffer get the signal again. But at this time, master side seems to behave crazy, it sends a empty PDU to client every about 2ms or maybe as soon as it receives an empty PDU from the slave.
726227 47816.865216000 Master Slave BLE Data 26 Empty Data PDU
726228 47816.866244000 Slave Master BLE Data 26 Empty Data PDU
726229 47816.867143000主从机BLE数据26空数据PDU
726230 47816.868015000 Slave Master BLE Data 26 Empty Data PDU
726231 47816.868887000主从BLE数据26空数据PDU
726232 47816.869742000从站主机BLE数据26空数据PDU
726233 47816.870613000 Master Slave BLE Data 26 Empty Data PDU
726234 47816.871492000从站主机BLE数据26空数据PDU
.......
726560 47817.196839000 Master Slave BLE Data 26 Empty Data PDU
726561 47817.197927000 Slave Master BLE Data 26 Empty Data PDU
726562 47817.198787000 Master Slave BLE Data 26 Empty Data PDU
726563 47817.199657000从机主BLE数据26空数据PDU
726564 47817.201497000 ab_mat5 BLE ADV 48 ADV_IND
726565 47817.202433000 ab_mat5 BLE ADV 48 ADV_IND
我希望这些信息给你们对这个问题更有意义，非常感谢。
Thanks!
zwang308，
您在当前实施中使用的SDK以及您拥有的开发套件是什么？据我所知，您使用的连接参数与DSP项目几乎相同。当您与设备连接时，您的假设是正确的，堆栈将通过在不要求应用程序执行任何操作时通过交换空数据包来保持连接。
From the 1st log i can see that your master stops sending empty packets in order to keep the connection alive so there is no response for the slave side, timeout occurs and the connection is lost when this happens perhaps you should check the state of your host.
From the 2nd log seems the slave doesn't respond to the connection request from the host, check how you are handling the connection request in your peripheral code, and check if the device reaches the connection confirmation.
关于第3个日志，这似乎很奇怪，我无法想象为什么中央将以如此高的速率开始发送空的数据包，特别是如果没有数据发送，中央本身或设备。
Thanks MT_dialog
I am using SDK 3.0.10.1.
The problem is the connection breaks randomly.
对于12ms连接间隔，有时连接进展超过一小时;但有时他们会在2分钟后断开连接。
After I change the connection interval to 30ms, the average connected time gets much longer. But they still disconnect randomly,
When they get disconnect, there is really no application activity. I assume the BLE stack will take care of the connection, send/ack empty PDU automatically during that time.
此外，即使他们断开连接，它们也应该能够重新连接。但是一旦他们断开连接，就无法再连接到奴隶，无论我使用我的主应用程序还是使用一些标准设备。苹果手机。
To me, it looks like part of slave's BLE stack is screwed up: slave could receive the connection request from master(it stops advertising) but it could not send an ack. So, the both side just disconnect after 1s. Afert that, slave begin to advertise again.
这些是我测试中得到的一切。
Thanks a lot for the help!
顺便说一下，我对所有测试使用相同的代码库。我确信从属侧发送连接请求确认，否则它们不会连接。同样，问题是Connect -----保持随机时间的连接---断开连接，从不能够重新连接。
谢谢，
zwang308，
I ve implemented a central and a peripheral on the SDK 3.0.10.1 (no profiles included) i ve set the connection parameters to the host identical with your's with a connection interval equal to 12.5 ms between a pro and a basic kit. So far everything seems correct and the connection lasts as long as i could watch (more than two hours) also i am able to reconnect to host, (in extended sleep mode yet). Have you implemented any profile or any other functionallity in order to try and reproduce your issue?
Thanks MT_dialog
Hi MT_dialog,
我所做的就像你的DSP项目一样。
当我收到包时，我开发I2C驱动程序并将数据放入NVRAM。在app_asynch_trim函数中，我拉动缓冲区并通过ble发送数据。
但在我的测试中，我禁用APP_ASYNCH_TRIM中的I2C驱动程序和拉动功能。在测试中，两个DA14580S在断开连接时真的无所畏惧。
从我的观察开始，他们一直在发送空的PDU一段时间，突然将主站暂停发送空的PDU。我们有方法要知道为什么大师停止发送空的PDU吗？我们可以从内核那里收到一条消息，以知道他们为什么断开连接。
对我来说，似乎他们随机断开连接。我们上周做了很多测试，有时联系良好超过16小时;有时他们会在2分钟后断开连接。
它真的很困惑我。
谢谢!
zwang308，
Can you run your master form keil and check when this issue occurs, what is the state of your master ? Also are your handlers indicate that there is a disconnection either by the master or at least by your slave when he stops receiving data by your host. You can place a break point to your device and check what you get as a disconnection reason. There is no way to check why the master doesn't send any data, an error indication or something like that since this should not happen the stack should always keep the connection.
Thanks MT_dialog
Hi MT_Dialog,
For the first time they disconnect. The error code on peripheral is 0x13(REMOTE USER TERMINATED CONNECTION) while the error code on central side is 0x08(CONNECTION TIMEOUT).
After that, the error code on peripheral side is always 0x08 and central side as 0x3e(CONNECTION FAILED TO BE ESTABLISHED).
I don't think the code actually stops at a point because both side is keep switching between advertising/scanning and connected state.
我们知道为什么会发生这种情况吗？
Do we have a method to soft reset the chip(run firmware from the beginning without reload the firmware or just reset BLE stack)?
Thanks a lot.
zwang308，
We haven't observed anything similar in tests we performed (i.e. the central to just stop sending packets) although we managed to track a cornercase where the peripheral isn't able to connect under specific circumstances, the patch for the specific cornercase isn't yet released. For this kind of situations we propose either to perform a sw reset to the 580 or reset the stack.
You can try to either issue a reset by using the SW_RESET field of the SYS_CTRL_REG and set the starting address to the sysram (please check the datasheet) although its not a good idea and reboot from the original image is prefered (download the code in the 580 using the bootloader) also you can try to send a GAPM_RESET command in order to reset the stack.
也是可以共享一些代码（中央和设备），以便看看，因为我们无法在我们身边复制问题？
Thanks MT_dialog
嗨mt_dialog，
Could you please provide me a e-mail address for sending the code? You could reach me in person through e-mail.
Thanks a lot,
zwang308，
问题是由于过时的SDK。
Thanks MT_dialog
Hi, MT_dialog.
I am suffering the same error as Mr zwang308's. I am using the sdk version V3.0.8. You said it was due to an obsolete SDK, please tell me which sdk is ok. Thanks.
Hi menson,
The latest SDK is the 5.0.4 for the 580 device.
Thanks MT_dialog