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
BLE status = 133 problem #1
Comments
Hi, |
I'm having this issue on a Nexus 5 running 5.1.1. We send an enter DFU command to the target, the target disconnects from my app (after ~3 seconds), I close the gatt, and then I fire up the DFU library intent service and it yields a 133 error after onClientRegistered(). Still trying to figure this out. I'm pretty sure its an app caching/le stack issue, because once the device is in DFU, I can launch the nRF Toolbox app and send it new firmware images without issue. |
Hi, |
We have also found some bugs in the new Android 5.1. The DFU was working much better on 5.0 and fails on 5.1.x. I still don't know if it's a bug out a feature, need some time to investigate. |
Yeah, we start the DFU service while in application mode. I receive a disconnect shortly after, and then I try starting the dfu intent service, which ends up failing during the connect phase. I've tried delaying 3, 5, and 10 seconds before connecting in DFU mode once its triggered. Also added retry code and changed the dfu lib to run on the UI thread, to no avail. I ordered a bluetooth sniffer so I can see what's going on at the transmission level, but I wont have it until mid week. I only work on the Android side, not the embedded app, so I'll just be sending the sniffing data to our firmware guys to see if they have any ideas. My suspicion is Android didn't cleanly disconnect form the peripheral, and has something unexpected or invalid in a cache causing the connect by the DFU lib to fail. I'll try my app out on some other versions of Android & different phones and see if it works there. |
Hi again. The DFU service should automatically start itself after successful jump to the bootloader mode. No need to start it again. |
Tried nRF Toolbox with our device and it toasted 'DFU service not found', so we've implemented the feature in a way that doesn't work out of the box when in application mode. Just thought maybe my issue was related to this ticket due to my logs being an exact match, but maybe it's something we're doing after application mode switches to DFU with our custom implementation. Thanks for the assistance |
Didn't realize the address changed when the device entered DFU mode. Problem solved :( |
Nice to hear that. |
Hi: |
The refresh() method is not in the public api. Reflections must be used to call it. It also may be removed one day without notice. |
Sorry; I also have one question:
|
refresh() method clears the device's list of services cached on the phone. It means that the next time the phone will connect to the device it will have to do the service discovery procedure. Without calling refresh(), when you call gatt.discoverService() and the phone had already discovered them before, it will just return you back the cached list without doing any operations over the air. It will be about 5 seconds faster and will save some battery on the peripheral.
|
Hey @philips77, sorry to revive this thread, but perhaps you have some insight on how to get around some similar 129 and 133 issues I'm having when trying to DFU? We're using the maven release of the library, Things work fine on our newer bootloaders, where DFU runs on a different MAC address than the normal application. But we still have some old hardware in the wild that we'd like to be able to update, which reuses the same MAC address for the application and the DFU service. Even then it works fine on certain phones, such as Moto E, but it only works about 10% of the time on other phones, such as Galaxy S5. On such phones, the other 90% of the time, the DFU library hits the following errors:
The full log output is attached here. In that log you'll also see a few random things we try before starting DFU, with 1 second delays between each step:
So anyway, if you happen to have any thoughts on what might be going wrong or how we might be able to fix it, that would be excellent! |
Hi, what I'd do is just clear the cache after you get onStateChangedCallback with state disconnected, before calling close() (before you start DFU service). The second service discovery before that may not be a good choice. Also keep in mind, that calling refresh() performs the service discovery if you are connected. It's asynchronous. The service discovery may take few seconds. You may also give some time after close using wait(600) (I see you give 1s). So, in summary:
You may also check the log in nRF Master Control Panel. I log there all ble related method on Debug level. Hope it helped |
Thanks for the tips Aleksander! I'll try them soon. |
@philips77 that helped to fix my issues on Samsung phones, thanks very much! Now I'm getting a different issue on certain newer phones (Nexus 5X and OnePlus 2). The DFU progress gets to 1% and then I receive this error:
Any guesses what could cause this error? The exact same device and zip archive work fine together on other phones. (Sorry to continue on this thread, just figured you might know what can lead to that error. Thanks!) |
Try to change the number of packets (before a receipt notification is sent) in the settings. Start from 1 and increase it slowly. You may also try to increase the connection interval in the DFU bootloader. The issue may be related to the speed of saving incoming packets on flash. The new phones may support more packets per connection interval which may be too fast for DFU. Also nrf52 needs a little more time to save, as it has more flash memory, and in the flash tech a page needs to be cleared before saved. |
FYI, I published a newer version of the DFU library on jcenter (0.6.1). Not related to your problem, but to this: https://devzone.nordicsemi.com/question/57250/android-6-master-control-panel-bonded-dfu-android-6-gets-stuck-in-a-loop/?answer=57307#post-id-57307 |
thanks @philips77 is there any way to change that setting other than changing the strange thing is that these phones work fine on devices that have our newer bootloader. so with the exact same hardware on both ends (phone and device), just changing the bootloader introduces the issue. anyway i'll let you know if i find anything! also, good to know about that nordic devcenter, maybe i'll bug you there next time ;) |
Hi, in toolbox's DFU profile you have the settings icon in the right top corner. There you can find Number of Packets, which sets the mPacketsBeforeNotification value. |
Thanks yet again @philips77 that was totally the issue! The highest I could get it to was 4, to work on both the OnePlus 2 and the Nexus 5X. In case anyone else comes upon this thread, here is the code I used: PreferenceManager.getDefaultSharedPreferences(getActivity()).edit()
.putString(DfuSettingsConstants.SETTINGS_NUMBER_OF_PACKETS, "4")
.commit(); |
I finally found where the error codes are defined: Unfortunately 0x85 (133) is just |
From my experience the error 133 is thrown in case of timing issue. This is when a command was expected but wasn't received. For example when device is not reachable after calling |
Android 5.0+ dfu is Ok |
Could you open another issue? This one is regarding error 129, as I can see. |
Find the problem, the embedded engineers changed the dfu state device name, so can not connect service,thank you, your project has given us great help |
Great to hear that! |
I still get this every so often. Any ideas on how to fix this? |
What seems to have improved the situation for me in a custom BLE connection implementation
This, among all other recommendations of running all commands from a single thread, not blocking BluetoothCallbacks, keeping a single BluetoothGatt, etc. BLE on Android is complex... Maybe tomorrow I'm facing the same issue on a different device :( |
I had the Error #133 problem. After months of research and pulling my hair out, I have found a solution that is not normally talked about. Your normal connect request looks something like this:
There is another version of the connectGatt command, with a 4th parameter. This parameter specifies what type of bluetooth device you are connecting to. I added a "2" to specify that I am connecting via Bluetooth LE. (it's called "transport", forgive me if my explanation is incorrect, but it solved all my problems) Try this:
And BAM, now my #133 nightmare is over (I pray)! |
Hi btmcmahan, I am also getting same error but not able to solve my problem with your work around. Please spare some time and have a look at this question https://stackoverflow.com/questions/48507782/how-to-write-byte-array-with-bluetoothgattcharacteristic-in-ble. Thanks. |
The transport parameter fixed my problem, but I also did a few other things. Try starting a ScanLE right before you issue the connect request. And try issuing the connect request from the same thread as the scan. Here is an article that helped me.
Lessons for First-Time Android Bluetooth LE developers I Learned the Hard Way
|
|
|
| | |
|
|
|
| |
Lessons for First-Time Android Bluetooth LE developers I Learned the Har...
Hamid Mukhtar
Background
|
|
|
On Wednesday, January 31, 2018, 11:39:00 PM CST, Chitrang Patel <notifications@github.com> wrote:
Hi btmcmahan, I am also getting same error but not able to solve my problem with your work around. Please spare some time and have a look at this question https://stackoverflow.com/questions/48507782/how-to-write-byte-array-with-bluetoothgattcharacteristic-in-ble. Thanks.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
mBluetoothDevice.connectGatt(context, false, callback);
mBluetoothDevice.connectGatt(context, false, callback, BluetoothDevice.TRANSPORT_LE); Ultimately, hardware equipment is needed to completely solve this problem. |
|
I am facing the ble status = 133 in android BluetoothGatt .
the log follow:
D/BluetoothGatt(16840): connect() - device: F0:13:C3:80:AA:C6, auto: false
D/BluetoothGatt(16840): registerApp()
D/BluetoothGatt(16840): registerApp() - UUID=653ae82e-5199-4ff2-8897-27b6ae925f3c
I/BluetoothGatt(16840): Client registered, waiting for callback
D/BluetoothGatt(16840): onClientRegistered() - status=0 clientIf=5
D/BluetoothGatt(16840): onClientConnectionState() - status=133 clientIf=5 device=F0:13:C3:80:AA:C6
In the sourcode the 133 means GATT ERROR .
And in my code i have user the refresh() before the gatt.close();
And I have use close() after disconnect();
But there are not any AndroidPhone have this problem .the Samsung S4 had meet much time.
and the Moto X is very nice in BLE.
How about try to reconnect the device while we meet the status == 133 or 129?
For some AndroidPhone the Ble develpment is no good.
Maybe my english is no good , Hope you can help me ,Thank you very much .
The text was updated successfully, but these errors were encountered: