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?
致以最诚挚的问候,
CD
Keywords:
Device:
You should use SDK 5.0.3 which fixes exactly this.
你好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
如果你用的是sdk5.0.3的话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
你好,乔西姆和迪奥拉先生,
Thanks for your quick reply.
在那之后,我使用DA14580开发工具包和prox\u peporter(定制成对)进行了测试。它可以与android6.0配对(它可以与LinkKey位正常工作。)
我们还检查了5.0.2.1+修补程序(5.0.3中的4个重要文件-arch\u patch.c和.obj文件)在DA14580开发工具包和prox\u reporter环境中是否正常工作。效果也不错。
现在我们正在检查RAM和堆的使用情况。因为我们以前的项目做得很好,但最近的一个不起作用。。。。文件大小变得越来越大,所以堆或堆栈边距可能不足以处理LinkKey位。我不知道,但有可能吗?堆文件的使用是否会因LinkKey位的不同而改变?
Thank you very much for your supports as always.]
Best,
CD
越来越多的补丁当然占据了更多的空间。只有8个单词可以直接修补,这也意味着如果需要更多修补程序,则需要一种占用更多空间的不同修补方法。然而,通常有改进的余地;补丁并没有真正优化。
If you look in arch_patch.c, you will find the following which is the patch that fixes the LinkKey bit:
//0x00031b95 smpc检查参数
SetWord32(PATCH_ADDR5_REG, 0x00031b94);
SetWord32(补丁数据5寄存器,0xb500df05)//smpc检查参数svc 5
and with the corresponding entry in the patch_table array:
(const uint32_t *) my_smpc_check_param,
这基本上意味着ROM smpc_check_param函数的修补副本被放在项目中链接的某个.obj文件中。
你可以解决这个问题在一个更大的问题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\u ADDR3\u REG,0x0002cb40);
SetWord32(补丁数据3寄存器,0xdf03e7f5)//smpc检查配对功能svc 3
with this code:
SetWord32(PATCH\u ADDR3\u REG,0x00031be8);
SetWord32(PATCH_DATA3_REG,0xbd00);//流行音乐{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