Hi,
我正在使用DA14580来通过UART传输数据。
当我添加UART连接时，设备将在AVG中每隔20秒与手机断开连接。
如果我不使用UART，设备不会断开连接。（来自主循环，我每10秒发送每10秒的UART请求）
user_app_disconnectis invoked after 20sec from connecting to the device via phone.
What could be the issue with my uart implementation that may cause the device to get disconnect? Or, how can I prevent the device from getting disconnected.
How can I figure out what is causing the disconnection.
谢谢，
Ezza.
设备：
调试后，调用Gapc_disconnect_ind_handler。
静态int gapc_disconnect_ind_handler（ke_msg_id_t const msgid，
struct gapc_disconnect_ind const *param,
ke_task_id_t const dest_id,
ke_task_id_t const src_id)
{
if (KE_IDX_GET(src_id) == diss_env.con_info.conidx)
{
vist_disable（param-> conhdl）;
}
return (KE_MSG_CONSUMED);
}
------------------------------
gapc_disconnect_ind const *param parameter has a reason for the disconnect.
/// Indicate that a link has been disconnected
struct gapc_disconnect_ind
{
/// Connection handle
uint16_t conhdl;
/// Reason of disconnection
uint8_t reason;
};
The原因value is 0x08.
Hi Ezza,
嗯，我可以假设的是你正在使用UART占据的手臂，并且在此期间没有安排的BLE事件，因此该设备从未按时上升到连接事件，最终您正在丢失连接事件和连接事件发生超时。您获得的断开原因是由于连接超时，表示您缺少连接事件。
Thanks MT_dialog
Hi,
谢谢回复。
我如何防止发生这种情况？
在UART事件期间，我不希望我的设备断开连接。
Hi Ezza,
也许你正在做一些time-consuming or blocking operations during the uart calls in main loop? What do you mean by "main loop"? As far as I know there is no main loop in the user application api, just callbacks. I guess we have to see your code to better understand that.
问候，
奥利弗
Hi,
由于DA14580没有“读取”指示事件。我不得不进入主拱门并在那里添加自定义代码。
In the main loop of arch_main, I call UART commands to update the DB of the ble, in order for the phone applciation read updated data.
For example, I have a counter on my ST firmware that is being updated all the time, and the application needs to read that counter. I keep it updated on the DB of the BLE by sending UART command from the main loop every 10s.
是否有任何方法可以提高Diremenction事件的超时的价值？（即即使我不捕获连接事件，也可以等待超过20s）。
Why sending\getting commands via UART causes a disconnection?
谢谢，
Ezza.
Hi Ezza,
to read the values periodically I would highly recommend to use easy-timer api instead of changing arch_main since this can easily disturb the ble timing. Here is how I would implement this:
#define READ_VALUE_INTERVAL 1000 // 1 => 10ms
static timer_hnd readValueTimer = EASY_TIMER_INVALID_TIMER;
static uint8 rxData[RX_SIZE];
void rxUartCallback(uint8 state) {
if(state==UART_OK) {
//处理rxdata
readValueTimer = app_easy_timer(100, readValueFromUart);
} else {
//错误处理
}
}
void ReadValueFromuArt（）{
UART_READ（rxdata，rx_size，rxuartcallback）;
uint8 cmd[] = { ... };
uart_write(cmd, sizeof(cmd), NULL);
}
void user_on_connection(uint8_t connection_idx, struct gapc_connection_req_ind const *param) {
...
ReadValuetimer = app_easy_timer（Read_Value_Interval，ReadValueFromuart）;
}
void user_on_disconnect( struct gapc_disconnect_ind const *param ) {
if(readValueTimer != EASY_TIMER_INVALID_TIMER) {
app_easy_timer_cancel(readValueTimer);
readValueTimer = EASY_TIMER_INVALID_TIMER;
}
}
问候，
奥利弗
Hi,
Unfortunately, it still the same issue. I changed my code and removed everything from arch_main and used easy_timer.
Also, even if I send events from the phone like "write", it still will disconnect in 20sec in avg.
连接是否稳定而不读取/写入特征，只在背景中持续读取UART上的值？
Hi,
即使我什么都不做（没有读，没有写），它也不稳定。
我刚连接到设备并等待它以断开连接。
Hi,
我在哪里可以厌倦断开连接事件，并阻止它发生？
它为我们提供了阻塞，因为设备不断断开连接，并且手机应用程序获得了异常，直到它最终成功读取来自BLE的所有值。这导致对性能的显着降低。
Hi Ezza,
You will have prevent any UART activity from overlapping your connection interval, the UART communication should be in bursts and not having the ARM occupied for long since if you do the ARM wont be able to program the BLE events on time. For example you could attach a UART logic in the .app_on_system_powered in order to process any UART events but you should not stay there for long, you should return KEEP_POWERED in order to force again the schedule_while_ble_on() to re-run in order to schedule any BLE events that will occur and then the SDK will run the .app_on_system_powered again for the rest of the UART activity. Regarding increasing the supervision timeout, i suppose that the now the timeout is allready large 20 seconds if increasing it this will save you from the disconnection depends on the connection interval that you are using, but again this is not a solution you should review your implementation in order not to loose the connection events during the UART interaction. You cant stop the disconnection from triggering, the message is comming from the stack as soon as the supervision timeout occurs, even if you prevent the message notfying your callback the device will still be disconnected.
Thanks MT_dialog