OTA upgradeable stack bootloader for PSoC 4 device, stack authentication problems

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

cross mob
Anonymous
Not applicable

Hey All,

I am using the example projects supplied by  cypress of OTA upgradeable stack bootloader for PSoC 4200 BLE devices. I am using CYBLE-214009-00 PSoC BLE Module and CySmart application on an android cellphone for the upgrades. The system works fine as expected, but I am having some trouble with authentication now and then.

During an expected procedure:

1. I use CySmart to scan, connect, and evoke services screen on the App

2. This results in an authentication request being received by the app:

S    ble  72 CYBLE_EVT_AUTH_REQ: security=0x2

S    ble  73 CYBLE_EVT_AUTH_REQ: bonding =0x1

S    ble  74 CYBLE_EVT_AUTH_REQ: ekeySize=0x10

S    ble  75 CYBLE_EVT_AUTH_REQ: err     =0x0

and the systems responds with authentication success.

3. I am able to navigate to bootlader service, which initiates the bonding successfully

Now if I disconnect the connection by navigating back to scan menu instead of uploading the firmware, the following happens:

1. In scan menu, I select the bootloader again, CySmart attempts to connect, and evoke services screen again

2. The PSoC sees the connection attempts, but without evoking any authentication request, responds with authentication Failure:

CYBLE_GAP_AUTH_ERROR_INSUFFICIENT_ENCRYPTION_KEY_SIZE Insufficient key size for the security requirements of this device or LTK is lost

3. The PSoC disconnects and CySmart fails to do service discovery and is stuck with a non-services to show screen.

Has anyone else seen a similar problem or give me some pointers to Android - PSoC authentication which is potentially manifesting in this behavior?

For additional information, the device is setup for Security level of Unauthenticated pairing with Encryption.

Any help will be greatly appreciated.

Thank you

-Sohail

0 Likes
1 Solution
Anonymous
Not applicable

I suspect that the CySmart isn't cleaning up/clearing the authentication upon closing or disconnecting. Potentially, you could modify the cysmart app code you are using to get it to handle this case, or push it as a bug fix to Cypress and see if they will update their master copy.

From the PSoC side, you can use these APIs to remove the authentication:

1)CyBle_GapRemoveBondedDevice(CYBLE_GAP_BD_ADDR_T *bdAddr).................Any device of your choice.

2)CyBle_GapRemoveOldestDeviceFromBondedList().............Remove the oldest device bonding information.

  

View solution in original post

0 Likes
5 Replies
Anonymous
Not applicable

It could be the app isn't disconnecting correctly in the fail-scenario? There might be an authentication mismatch: Using an authentication for only one of the two parties will cause an authentication failure, using the wrong/old data will cause a failure, and if the bootloader has code that throws the authentication error upon an internal application error for some less-related custom-application reason, then it will cause a failure

Most likely the bootloader is dumping the LTK value when entering bootloader menu? Even though the phone disconnects, that doesn't mean the PSoC device resets/exits bootloading...

0 Likes
Anonymous
Not applicable

Hey E. Pratt

Thank you very much for reply. Yup, I agree with your assessment.

Following similar logic, I tried to enforce either PSoC or Master device to drop any previous authentication keys, and start anew every time. I tied to do this in two ways:

1. On PSoC, I reset the device through software reset, and clear the flash data region of the BLE Stack

2. On The Master Device (Android Cellphone) I restart the bluetooth from settings, relaunch the app and try again

But this did not seem to "flush the authentication" and the same problem happened. My suspicion is that the SmartPhone may not be flushing the authentication keys, until it fails to use the previous one.

I am fairly certain the it is possible to build a non-authentication based "just works" bluetooth connection between PSoC and Smartphone App, just that I will not be able to use CySmart in that case, and will have to build a custom App.

But this is a not a major problem, rather a corner case, where the user is trying to reconnect right after dropping a bonded connection through CySmart (the bootloaded app uses a different non-authentication based profile and does not exhibit the same problem) so was wondering if there is a way to flush authentication and always start anew, so CySmart can still be used seamlessly.

0 Likes
Anonymous
Not applicable

I suspect that the CySmart isn't cleaning up/clearing the authentication upon closing or disconnecting. Potentially, you could modify the cysmart app code you are using to get it to handle this case, or push it as a bug fix to Cypress and see if they will update their master copy.

From the PSoC side, you can use these APIs to remove the authentication:

1)CyBle_GapRemoveBondedDevice(CYBLE_GAP_BD_ADDR_T *bdAddr).................Any device of your choice.

2)CyBle_GapRemoveOldestDeviceFromBondedList().............Remove the oldest device bonding information.

  

0 Likes
Anonymous
Not applicable

Hey E. Pratt,

Appreciate the help.

I tried to implement the authentication removal on PSoC but it did not help. But the CySmart suspicion ended being true. After a bonding and disconnection event, when I go and look into Android Bluetooth Settings, the bootloader device shows up as a paired device. If I remove the device from paired list by clicking "forget", the "no services found" problems does not happen, and new authentication is established between the PSoC and CySmart.

This may not be a solution that I was hoping for, but at the least I know where the problem is originating from. I will try to follow up your advice regarding CySmart app, and weigh which option is better.

Thanks

-Sohail

Anonymous
Not applicable

If you open a support case with Cypress, you might be able to get one of the FAEs to fix the bug in the cysmart app, but it would be a hit or miss depending on time/cost/etc that they decide for the bug fix's worth.

Glad you isolated the problem though

Good luck with your endeavors

0 Likes