Please check the reason for the CYBLE_EVT_AUTH_FAILED event. You can read it from the event parameter of that particular event. Please inform this to us.
Please use the latest version of BLE component i.e BLE v3.64 and check once. Also, is it happening with particular pairing method or all the pairing methods.
Please attach a demo project that is able to pair with previous versions of Windows and not with present version of windows.
Thanks for your reply.
Here is a process to reproduce this issue:
From Creator 4.3, open the HID Mouse example.
Update BLE component to 3.63
Download to Kitprog
In Windows 10, add device.
Device should pair sucessfully and cursor moves as per example.
Close and re-open Creator
Open any other example project (or open the previously-saved example mouse again)
Change BLE address to avoid overlap
Build and download to Kitprog.
In Windows 10, the first device will be in the device list but disconnected (it makes no difference if connected or not)
Attempt to pair
Error "Try connecting your device again"
The reason code is shown in my first port in the UART prinout, it is reason 8, which is "Unspecified reason".
At this point another device (I have a Microsoft mouse for testing) can be paired even if the first Cypress device is still in the device list. The issue only happens if two Cypress devices are attempted to be paired, but the type of project is unimportant.
I have attached the project which can be opened twice (change the address) but this is not strictly needed as any 2 example projects can be used to replicate.
This looks like a bug specific to (and in the BLE stack of) Windows 10 version 1909. As you mentioned, we have tested with version 1703 and we are able to pair multiple times with the same name (but different BLE Addresses). Result from 4 times pairing:
As bonding is per BLE Address, changing the BLE address should have made Windows beleive that this is a new device (which is what happens with my version of Windows). Please make following changes: Along with the BLE Address, change the Name of the device also (Say BLE Mouse 1). If this pairs then it means that with the new update, they are saving and comparing the device name also.
As mentioned in my original post the issue happens with any two devices using this platform. For example if the second device is the HID keyboard or even Battery level Demo, or any of the examples, the issue happens.
if the second device is not a Cypress device it will pair.
I just double checked this again by renaming the mouse device name.
Sorry for the redundant questions. We understood the problem.
Please note that the company ID is sent to the peer even before the pairing starts. It is shared as part of Version information in the VERSION_IND PDU. This can not be changed and will always be shared with the peer as soon as the link is up.
From above, we would like to say that from Cypress side, there is no issue from our BLE perspective associated with Windows OS version. The BLE spec remain unchanged from our side irrespective of the OS version.
We request you to enquire with Microsoft regarding this issue.
I agree with your view that this is a Microsoft issue.
But it would surely be a concern for Cypress than one of its Bluetooth platforms will not fully function with the worlds most popular OS.
I will attempt to raise this with Microsoft myself but not sure how far I will get.
Yes. You are correct. This would be definitely our concern.
We have forwarded this issue to our BLE stack team. They will be looking into this issue on priority basis.
I will let you know if we find any reason at our side regarding this.
Meanwhile, please check with Microsoft too from your side.
As a workaround for the issue you are facing, add CyBle_GapGenerateKeys API in stack_on event as shown below.
Please check and update whether this resolves the issue.