Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
We have a stress test running between two 737TAG dev boards. Code is based on hello_client/sensor. Master connects to the sensor, reads battery characteristic 10 times, then disconnects and connects again and so on in a loop.
Works flawlessly for about 5 minutes, then we get disconnect event with reason BT_ERROR_CODE_LMP_RESPONSE_TIMEOUT = 0x22 given by emconinfo_getDiscReason(). Disconnect always happens after ~40 seconds since requesting battery level characteristic read. After it, connect still works, but the battery read fails with the same error again and again.
So the question is what does LMP mean and what is the reason of such error? How to make Bluetooth functional again after LMP error happens? Problem is 100% reproducible in our environment.
Thanks for the post. This is indeed limitation of the BT spec which is not verified on the API level. You should not try to Create another connection until first attempt is completed. In your app you should cancel the attempt using blecen_Conn(NO_CONN...)