Hello.
After pairing with a tablet or computer, if you leave it for a few seconds without operating it
I wrote out the cause of the disconnection by debugging.
"Error 34 (0x22): GATT CONN LMP TIMEOUT"
What are the possible causes and countermeasures?
Hi,
Which SoftDevice version are you using?
BLE_HCI_STATUS_CODE_LMP_RESPONSE_TIMEOUT (0x22) means that a link layer procedure has timed out (data length negotiation for instance). The timeout is 40 seconds, so the easiest way to find out which procedure it was that timed is to get a sniffer trace and see what happened 40 seconds prior to the disconnect.
It may be caused by several reasons, for instance if the application does not not respond to certain SoftDevice events.
Hello.
Thank you very much for your answer which will be right away.
≫Which SoftDevice version are you using?
S132 is being used.
≫get a sniffer trace and see what happened 40 seconds prior to the disconnect.
After a packet was captured.
"LL_TERMINATE_IND" but a slave showed that he's sent and cuts.
"LL_TERMINATE_IND" but sent timing.
"The one of the ble_conn_params_init_t" "I found out that it's dependent on next_conn_params_update_delay".
Therefore a cut thing died to change "next_conn_params_update_delay" for 24 hours from 5 seconds as a temporary measure.
"Can't the reason that LL_TERMINATE_IND" is sent and the above measure have a proper basket view?
I'll give you trouble and I'm sorry, but please take care.
Einar san
Also I'm sorry for your trouble many times.
Way of my upload was bad.
I look forward to working with you.
Hi,
I wonder if you may be seeing a similar issue as in this thread, and that the phone is misbehaving. Which phone with which Android version are you using? So you see this issue also with other central devices?
Einar
Einar san
Thank you very much for your help.
≫Android version are you using?
Answer os ver. for tablets and Bluetooth Ver.
Android 7.0
Bluetooth 4.0
Above, thank you.
Hi,
I see. Can I ask you which specific tabled model you are using as well? Also, I am very interested to know if you are able to reproduce this issue with other devices, or if it is only that specific model?
Br,
Einar
Einar san
We become indebted to.
I recognized that the table model is the model number of the tablet, so
I will answer as follows.
Model: PC-TE507 JAW
Also, since it was reproduced on a Windows 10 notebook PC,
I will send you the log.
No3754: Pairing
No4646: Disconnect
Disconnect_Win10.pcapng
We have another question.
nRF Connect v3.6.1 --I am writing software using Programmer.
Is it possible to get and display "CRC" or "checksum"?
I would like to use it at the time of production to check whether the software can be written normally.
I'm sorry, but please tell me.
Einar san
We become indebted to.
I recognized that the table model is the model number of the tablet, so
I will answer as follows.
Model: PC-TE507 JAW
Also, since it was reproduced on a Windows 10 notebook PC,
I will send you the log.
No3754: Pairing
No4646: Disconnect
Disconnect_Win10.pcapng
We have another question.
nRF Connect v3.6.1 --I am writing software using Programmer.
Is it possible to get and display "CRC" or "checksum"?
I would like to use it at the time of production to check whether the software can be written normally.
I'm sorry, but please tell me.
Hi,
The sniffer trace with the Windows 10 master shows that the computer disconnects two times first at #3802, then at #4546. In both cases the disconnect reason is 0x13 (remote user terminated connection), which in itself is not an error. Did you get an error on the nRF side in this case as well?
Can you share your code which causes this behavior? Is it possible to reproduce this on a DK?
Regarding programming there is no support for calculating and displaying a checksum of the flash of using the programmer app in the programmer app. The closest you get with Nordic tools is the --verify option of nrfjprog, where you must supply a hex file and the flash of the target is compared with the hex file.
Einar
Einar san
We become indebted to.
Thank you for your contact.
For 0x13 disconnection
I understand that it is not an error in itself.
If you check it again,
BLE_GAP_EVT_DISCONNECTED occurred in Reason22.
This phenomenon is caused by connecting another company's application on our board and tablet.
It is occurring. (Not reproduced in DK)
We will send you the following, so please give us your opinion.
1. 1. BLEControl.c source code
(Excerpt so as not to include product information)
2. 2. BLEControl_log.txt Soft log (disconnection occurred at L53)
3. 3. Disconnect.pcapng Wireshark packet capture (disconnection occurred in No3592)
When the source code L50 is enabled, the above phenomenon does not occur.
Thank you fDisconnect_log.zipor your cooperation.
Hi,
Thank for these files. They were much more informative. Here I see from the sniffer trace (Disconnect.pcapng) that the nRF disconnects with reason BLE_HCI_CONN_INTERVAL_UNACCEPTABLE (0x3B) in #1977, #2783 and #3592.
You write that you do not see this if you include line 50, which delays the next connection parameter a very long time (24 hours, which I assume is longer than the time you test). Therefore my first assumption was that the conn_params module disconnected, but that is not the case as you have set disconnect_on_fail = false.
The actual reason this fails is that you explicitly disconnect on the BLE_CONN_PARAMS_EVT_FAILED event in your ConnectParamsEventHandler() function, with the reason BLE_HCI_CONN_INTERVAL_UNACCEPTABLE. So the nRF is doing exactly as you would expect with this code. If you do not want to disconnect even when you do not get the connection parameters you request, you should remove line 670 - 678 in your BLEControl.c.
Einar
Einar san
Thank you for your contact.
As you answered,
By disabling the disconnection process at the time of BLE_CONN_PARAMS_EVT_FAILED event
The problem no longer occurs.
Thank you very much for your support.
We become indebted to.
Let me ask you an additional question about advertise.
・ Question
After starting the advertisement and passing "APP_ADV_DURATION (180s)",
Advertise will stop and sleep.
If you want to continue advertising without going to sleep
Should I resume advertising when the BLE_ADV_EVT_IDLE event occurs?
In that case, the function to call is
"Ble_advertising_start"
"Ble_advertising_restart_without_whitelist"
Which one?
We apologize for the inconvenience, but thank you.