- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
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.
BR, Andrey
Solved! Go to Solution.
- Labels:
-
ReadWrite Characteristics
-
WICED Sense
- Tags:
- lmp
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The error codes are BLE Spec related. There is one thread here that discusses them: What does 08 returned by emconinfo_getDiscReason() mean?
But there are several others as well.
link manager protocol = LMP
There are entire sections of the BLE spec devoted to the LMP and its operation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, I saw that thread with solution to reset the chip. But isn't it a HW/FW bug which should be fixed some day by Broadcom? Resetting the whole chip does not seem to be a good option, especially when there could be other connections which are working fine. Reset will drop all obviously.
Clarification: I was referring to this post http://community.broadcom.com/message/9952 in relation to chip reset. I can understand that LMP may fail sometimes and require reconnection, but in our case it starts to fail permanently just after 5 minutes of work and only reset of the master board helps.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We spoke to the developers and unfortunately, reset is the only option.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks mwf_mmfae, I keep this question as "answered" unless this error causes some serious problems in our products.
Based on our experiments we have found out that this error seems to be triggered when there are more than one outstanding connection request initiated by blecen_Conn API. In other words, when blecen_Conn is called _before_ previous connection request has been completed. This seems either like a bug in the firmware our some undocumented limitation of the API. Can you please double check are multiple outstanding connections supported or not?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...)