Hi,
When DA14583 connects to Xperia Android 6.0 device, we got "Pairing Failed" from DA14583.
The issue seems to be related with the LinkKey bit at LE Key Distribution on Pairing Request. This bit is added in Bluetooth Core Spec. Version 4.2, and it was reserved bit in 4.0 and 4.0.
When we tested Pairing sequence using Nexus 6 (android 6.0), the pairing worked well because Nexus 6 doesn't use LinkKey bit. (I believe Xperia's implements is right. Because Xperia expose it use version 4.2.)
I think this procedure was handled by SDK, so could you check it?
I attached detail information, so could you check them please?
Best Regards,
CD
Keywords:
Attachment:
Device:
You should use SDK 5.0.3 which fixes exactly this.
Hello Joacimwe,
Thank you so much for your comment. I've assumed so.
Actually we use SDK 5.0.3... Are there any settings for it to apply patches or something?
What is a difference between 5.0.2 and 5.0.3?? Is it a object part? or C file?
I think the SMP part is a object part, so it is embedded in ROM as a hardware. Is fix code included in patch object, isn't it?
How does patch object actually work? We are using OTA solution and using mkimage tool. Are there any important methods/factors for using patch object?
So sorry for many questions, but we do use 5.0.3 and I think the problem is in our usage/environment of SDK.
Thank you very much,
CD
If you use SDK 5.0.3 it should work directly without modifications or settings. The important files are arch_patch.c and the .obj files. You can check how the patch looks like for 3.0.10.1 here:http://support.dialog-semiconductor.com/resource/patch-release-sdk30101. I guess the diff between SDK 5.0.2 and 5.0.3 looks similar.
If you wonder how the ROM patching works in detail you should take a look at section 2.2 inhttp://support.dialog-semiconductor.com/resource/b-002-da14580-applicati.... Basically you can replace 8 32-bit words in ROM. However there should normally be no reasons for customers manipulating the patches, as those are normally handled by Dialog.
Have you tried to run some SDK 5.0.3 example directly, such as the proximity application?
嗨,CD,
Joacimwe is correct, its was a known issue and should be fixed in the SDK5.0.3. The fix is patch in the ROM code and not a source code. There aren't any settings that you should apply, if you are using the 5.0.3 not the 5.0.2 this should work. You can also find the patch where is indicated and have a look (this is included in SDK5).
Thanks MT_dialog
你好Joacimwe和MT_dialog,
Thanks for your quick reply.
After that, I tested using DA14580 Dev-kit and prox_peporter(customized to pair). And it can pair with Android 6.0. (It can work with LinkKey bit properly.)
And we also checked whether 5.0.2.1 + patches(4 important files - arch_patch.c and .obj files in 5.0.3) works well or not on DA14580 Dev-kit and prox_reporter environment. It works well too.
Now we are checking RAM and heap usage. Because our old project works well, but recent one doesn't work.... The file size have become bigger and bigger, so heap or stack margin may not be enough to handle LinkKey bit. I don't know, but it it possible? Does usage of heap file change depending on LinkKey bit?
Thank you very much for your supports as always.]
Best,
CD
More and more patches of course take up more space. The thing that only 8 words can be patched directly also means if there are more patches needed a different patch approach is needed that takes up more space. However there are usually room for improvement; the patches are not really optimized.
If you look in arch_patch.c, you will find the following which is the patch that fixes the LinkKey bit:
//0x00031b95 smpc_check_param
SetWord32(PATCH_ADDR5_REG, 0x00031b94);
SetWord32(PATCH_DATA5_REG, 0xb500df05); //smpc_check_param svc 5
and with the corresponding entry in the patch_table array:
(const uint32_t *) my_smpc_check_param,
That basically means a patched copy of the ROM smpc_check_param function is placed into some .obj file you link in in your project.
你可以解决这个问题在一个更大的问题t way. Take back the patch files used by SDK 5.0.2.1.
Then you replace this code:
//0x0002cb43 smpc_check_pairing_feat
SetWord32(PATCH_ADDR3_REG, 0x0002cb40);
SetWord32(PATCH_DATA3_REG, 0xdf03e7f5); //smpc_check_pairing_feat svc 3
with this code:
SetWord32(PATCH_ADDR3_REG, 0x00031be8);
SetWord32(PATCH_DATA3_REG, 0xbd00); // POP {pc}
That's all that's needed and you should see that this solution takes less space than how it's done in SDK 5.0.3.
Note that the smpc_check_pairing_feat patch is only important if you use the central mode on the DA14580, which I guess you're not.
嗨,CD,
I cant see the connection between the memory usage and the Link key bit, yes the patches are making the file footprint larger but i cannot see the relation between this and the behaviour of your device.
Thanks MT_dialog
Hi Joacimwe and MT,
I just assumed SMP layer function in SDK uses malloc() or something memory assigning by using heap area, and if LinkKey bit is set, the usage of heap area or assigned area may become larger... (This was just our guess...) Now, we can't reproduce this issue now, it seems we missed the testing procedure or something... 5.0.3 works well, and we can not see any problem now on this. We would like to see how it goes...
Thank you so much for your great supports both!
Best,
CD