-
Notifications
You must be signed in to change notification settings - Fork 217
Missing house keeping logic for ATT class #127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi @dreamstyler . However, thanks also for this report #129 . I will address it in the coming days! |
Thanks for your reply, I will check later to give some sample code. Please find below a log dump
NOTE: It would be good to have a way to check what MTU was negotiated with the other BLE device as this informs one on how much data can be transferred. (this is stored on peers but there is no where to check what that is) There are a few cases where this below happens, but id does seem to keep working At there points is when coms stops working and a reboot is required. Its as if the Ardrino BLE module freezes and does not accept new requests from other BLE device. Did try query the BLE mac address of the Arduino at this point and it return 0's. Click here to view log
|
Added a sample project, the actual project is much larger. P.S. I am using a "arduino iot 33 nano" |
The ATT class is missing an end() function to clean up ATT variables. This end function then needs to be called inside BLELocalDevice::end().
Proposed function:
I set up my BLE as a peripheral and use it to stream data to an android device. The mobile requests data using an index (writes to a characteristic) and then my IoT33 nano has a data characteristic which it updates. The mobile app listens for change notifications on the data characteristic, and once it read it requests the next index. I am using a MTU of 242.
This works ok but the Arduino seems to crash at some random points. From 10000 data requests it can crash at any point.
To address this I restart the BLE module by calling end() and then being().
I noticed that sometimes the MTU from the peers in ATT were not being cleared.
After further investigation, I noticed there is some house keeping missing in ATT end() to clean all the _peers.
Not sure if this is an issue, but disconnect() should probably clean up all _peers even if HCI.disconnect(_peers[i].connectionHandle) does not return 0;
The text was updated successfully, but these errors were encountered: