Problem with BLEAPP tutorial

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

I was following the tutorial for PSoC® Video Tutorial Series: How to Create Android Apps to Interact with Cypress BLE when I downloaded the source code and tried to run the program. The PSoC code appears to work correctly because I could control the red LED and receive CapSense data using the CySmart app on my phone.

When I loaded the PSoC code in Creator 4.1, it did ask for me to hit Project > Update Components because the design "uses an older version of a component than is available in your dependencies." This seemed to work fine. Other than that, there were no changes to any files.

The Android app works up until the point you hit the "Discover Services and Characteristics" button. The last couple of lines in the console of Android Studio 3.0 reveal the error.

D/MainActivity: Connected to Device

D/BluetoothGatt: discoverServices() - device: 00:A0:50:AE:79:E3

I/Choreographer: Skipped 261 frames!  The application may be doing too much work on its main thread.

D/BluetoothGatt: onSearchComplete() = Device=00:A0:50:AE:79:E3 Status=0

W/BluetoothGatt: Unhandled exception in callback

                 java.lang.NullPointerException: Attempt to invoke virtual method 'android.bluetooth.BluetoothGattCharacteristic android.bluetooth.BluetoothGattService.getCharacteristic(java.util.UUID)' on a null object reference

                     at com.cypress.academy.ble101.PSoCCapSenseLedService$3.onServicesDiscovered(PSoCCapSenseLedService.java:378)

                     at android.bluetooth.BluetoothGatt$1.onSearchComplete(BluetoothGatt.java:304)

                     at android.bluetooth.IBluetoothGattCallback$Stub.onTransact(IBluetoothGattCallback.java:217)

                     at android.os.Binder.execTransact(Binder.java:446)

Debugging that area of code, I see that line 376 of PSoCCapSenseLedService.java is returning null so the error is happening on the next use of mService.

line 376: BluetoothGattService mService = gatt.getService(UUID.fromString(capsenseLedServiceUUID));

The uuid being passed to getService() is 00000000-0000-1000-8000-00805f9b34f0. mServices has 3 services and their UUIDs are:

00001800-0000-1000-8000-00805f9b34fb

00001801-0000-1000-8000-00805f9b34fb

0000cab5-0000-1000-8000-00805f9b34fb

getService() loops through these and does not find a match for the uuid it was passed and so it returns null.

Can someone help me with the fix for this?

0 Likes
1 Solution
Anonymous
Not applicable

Hi,

This could be a problem of GATT DB Cache. Your phone might store the GATT DB of previously connected in it's cache. So when it might be expecting a previous version of GATT DB. It will return null without even doing a proper GATT Discovery. So the App must ensure that this cache is cleard / ignore and that the discovery is forced.

Apparently the CySmart source code handles the GATT DB Cache issue, so there is no problem while using CySmart

Temporary solution is to clear the cache of Bluetooth and the Concerned App.

For actual solution, you need to add some piece of code in your android app source code. Please refer

How to programmatically force bluetooth low energy service discovery on Android without using cache ...

Regards,

- Madhu Sudhan

View solution in original post

7 Replies
Anonymous
Not applicable

Did you check what the UUID is on the project before and after you updated the project?

It could be that the act of updating the project changed the UUID values in the services of the BLE component, causing the mismatch when trying to run the test programs.

You can manually set the UUID values in the psoc creator as well if all else fails. If the UUID was set to be randomly generated, then updating the project will change the "random UUID" value, and thus cause the break you observed.

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

I could not figure out how to find the UUID before the update, but I can see what they are now. I attached a video showing the values I am seeing.

I find four relevant UUIDs in Android Studio

00000000-0000-1000-8000-00805f9b34f0 is exactly the ledcapsense service UUID in PSoC Creator, Android Studio is correctly looking for this string.

The UUIDs that are discovered by the Android app are the three below.

00001800-0000-1000-8000-00805f9b34fb seems to be the Generic Access with UUID 1800 in PSoC Creator

00001801-0000-1000-8000-00805f9b34fb  seems to be the Generic Attribute with UUID 1801 in PSoC Creator

0000cab5-0000-1000-8000-00805f9b34fb I don't know where this one is coming from.

The PSoC code has the correct UUID for the custom service and Android is looking for the same UUID. But when the services are discovered that UUID is not among the strings returned. How do we get it to be discovered?

0 Likes
Anonymous
Not applicable

When I use the LightBlue app (or Nordic Connect) to connect with the PSoC, I can see the UUIDs are discovered as expected and what is written in the Android Studio as what they should be.

But when I debug the Android app, it is looking for the custom service which should be 00000000-0000-1000-8000-00805f9b34f0 but the service is discovered as 0000cab5-0000-1000-8000-00805f9b34fb.

If I google the new UUID, I see a few GitHub projects that have a GattAttributes.java file that defines CAPSENSE_SERVICE to be that UUID.

If I change the service UUID the Android app is looking for to 0000cab5-0000-1000-8000-00805f9b34fb, it will find it. However, there is only one characteristic listed, instead of two as it should be and as it is in the picture. This characterstic is 0000caa2-0000-1000-8000-00805f9b34fb. Referencing the same GattAttributes.java file, this string is listed as CAPSENSE_SLIDER.

The Android app will not find the device when the "Search for Device" button is pressed because it is searching for the changed UUID. So when searching for the device to connect, it sees the original advertised service UUID, but after connecting, the UUID is being changed when we try to discover all of the services.

If I try to change enough UUIDs I can get the program to continue on past the discovery phase, but neither functionality works.

What is causing these changes when the services are discovered through Android?

IMG_2277.PNG

0 Likes
Anonymous
Not applicable

If I change the service and both characterstic UUIDs to random values, the results in the Android app from getServices() is exactly the same as before (as recorded in attached video above). The service we are searching for is listed as 0000cab5-0000-1000-8000-00805f9b34fb.

But it still connects with the device because the board is advertising the new random UUID (the same that Android is looking for), but changes once getServices() is called.

Is there something in PSoC creator that needs to be changed to prevent this behavior and make it respond to getServices() with the same UUID it used to advertise?

0 Likes
Anonymous
Not applicable

Hi,

This could be a problem of GATT DB Cache. Your phone might store the GATT DB of previously connected in it's cache. So when it might be expecting a previous version of GATT DB. It will return null without even doing a proper GATT Discovery. So the App must ensure that this cache is cleard / ignore and that the discovery is forced.

Apparently the CySmart source code handles the GATT DB Cache issue, so there is no problem while using CySmart

Temporary solution is to clear the cache of Bluetooth and the Concerned App.

For actual solution, you need to add some piece of code in your android app source code. Please refer

How to programmatically force bluetooth low energy service discovery on Android without using cache ...

Regards,

- Madhu Sudhan

Anonymous
Not applicable

Thank you Madhu! That was exactly it.

The service and characteristic UUIDs I was seeing in Android Studio were from a previous project I had done on the PSoC 4. I should have tried turning clearing the phone data and restarting it, but I had not thought about the Bluetooth application caching data.

Anonymous
Not applicable

Sorry I didn't respond over the weekend, but it looks like Madhu is spot on with his assessment

Epratt

0 Likes