BLE bonding data in stack and application for an Upgradable Stack Project

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

cross mob
lock attach
Attachments are accessible only for community members.
manusharian
Level 4
Level 4
25 replies posted 10 replies posted 10 questions asked

Hello everybody,

I will reopen a topic that was already asked here Re: OTA Bootloader Bonding Problem  and also encountered by us from the beginning (and many others as we search the forums).  We did not need the OTA feature until some short time ago and we have the problem with bonded data that is not consistent from Application to Stack project of our OTA upgradable stack project. In the linked attached a step by step description of the problem is present. Basically we use some custom boards based on CY8C4248LQI-BL573 chip and we implemented in application project the privacy features from example BLE_4.2_DataLength_Security_Privacy. Everything is fine in application and also the bonding is ok with persistent data between resets, on-off, and OTA upgrade. The problem is that when the code is trying to do an OTA and the execution goes to Stack project the bonding data is not present -> the user has to remove the device from system devices on android/ios and remove from devices list when using the Cypress dongle. Moreover in our example you cannot do an OTA if there is no bonded devices when the execution reached the stack project.

Attached is an example project that can be easily run on PSOC 4-ble dev board. If anyone has successfully realized this or have some hints in this direction it would be great. I also opened a ticket for technical support at cypress but as from the last response I was redirected to this forum for more help.

Execution of code: using dongle or smartphone connect to device, pair code is 123456, fixed. After connecting you can write to the only writable characteristic the value 0x0D. The code will go in Stack and if bonding data is not present the code will go again in application. We tried several approaches but every time you need to unpair the device from system devices which is not acceptable. The user experience will be very bad and basically the OTA is useless.

Best regards,

Marian

0 Likes
5 Replies
Anonymous
Not applicable

I agree with the comments in the linked thread that the solution is to make sure you are saving the keys for the associated bonds. Otherwise, it sounds like the bootloader isn't performing what it should be?

0 Likes

Hello,

What exactly means to make sure the keys are saved? It seems that in application the keys are correctly saved since the phone can easily reconnect after reset / on-off. Also in a test project where I bond a phone, then performed an OTA with another device, the bonding in application to the first device is still present. What I encounter is that in stack project the bonding data is not present. In the attached example it can be observed that the bonding list in stack is empty and in application have one bond. You can run the example on dev board and see the prints on P12.6 of psoc 5 present in dev board using 57600 baud rate.

Also please note that in the attached post the user used a Fixed Stack OTA while I am trying to share data in an Upgradable Stack OTA where the stack and application are different projects.

0 Likes

Hello,

Because we were unable to solve this problem yet, we start to make an workaround. Basically from our test we observed that bonding data for Application and Stack are place in completely different flash memory areas. The area for Stack is at the last lines of stack end while the application stores the data in the last lines of the memory except metadata. Therefore we just make a very ugly mirroring of the memory from application to the stack by taking all the data stored by application and update the address of cyBle_flashStorage variable in stack. This hack is working for now but we believe the sharing can be done from linker files somehow.  More test are still needed but we are also waiting for some helpful insights from Cypress engineers or anyone that had this problem, which seems very strange at least.

0 Likes
Anonymous
Not applicable

The workaround you describe sounds like the best approach unless someone from cypress' team can clarify if bonds are available to the bootloader from the application memory.

0 Likes
Anonymous
Not applicable

The bootloader tends to have isolated code/flash, so the fact that the bonds/keys are unavailable for the bootloader may be intentional from a general application standpoint.

0 Likes