cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC 4 MCU

LiSi_1648326
New Contributor II

Hi, I am using CY8C4248LQI-BL583 and Launcher - Stack - Application configuration.

Currently having an issues providing OTA functionality to iOS app, because, after bonding to application, when it jumps to stack and tries to connect, it complains about "Peer removed pairing information".

It happens that iOS tries to pair, but since the Stack and Application has its own checksum exclude areas, they have its own bonding information, so the pairing with stack fails, because bonding information stayed with application, moreover both of them have the same MAC address, and this is what smartphone does not like.

Question - is there an easy way to share bonding keys between the two?

We can make workaround, to copy one bonding information to another, from Application to Stack project, but maybe there is a way to link them to one place using linker scripts?

0 Likes
1 Solution
7 Replies
VenkataD_41
Moderator
Moderator

Hi,

You need to try the following steps:

1. By marking the section (EEPROM section where bonding data is stored) as NOLOAD in the linker script.

2. Make sure both devices have the same number of devices configured in the bonding list.

Can you please let us know the problem when you treat both Stack and Application as different devices?

Thanks and regards

Ganesh

0 Likes
LiSi_1648326
New Contributor II

Hi! Thank you for your reply.

Well the problem is that the MAC address is the same. If iOS has previously connected to Application, and now tries to connect to Stack to do OTA, will fail to connect, because the bonding information is not valid. In this case user has to manually go and delete the bonding from Bluetooth settings on the phone.

From your explanation, as I understand NOLOAD should allow us to have the same variable on the same address without giving a linker error?

But I think there is another question needs to be answered: which address to use for bonding, Application (at the 3rd last row of the flash) or the Stack (last row of Stack)?

When I tried manually place any variable, even one uint32_t in the Stack project, just having it as a constant, I found that it impacts calculation of metadata end address. Then the Launcher always treats Stack as invalid application...

0 Likes
FrSt_4749731
New Contributor II

Hello,

We are also trying to do the same thing. Did you manage to solve the problem? If yes and advice would be really helpful.

The reason for the user to see only one BLE even if the device is either in the normal mode or in the bootloader mode would be easy to use. As now the user has to go to the Android system settings and perform unpair/pair manually when we perform FW upgrade of the BLE stack.

Thanks for the answer, Frenk

0 Likes
LiSi_1648326
New Contributor II

Hi Frenk,

We did a messy workaround mentioned in the original message.

When we compile Bootloader/Stack, we populate cycodeshareimport.ld file with an address of Bootloader bonding data address, based on .map file, adding a line:

PROVIDE(cyBle_StackFlashStorage = 0x1ef00);

Then, on application, before jumping into bootloader, we copy Application bonding data to Bootloader bonding data:

drv_flash_write((void*)&cyBle_flashStorage, (void*)&(cyBle_StackFlashStorage), sizeof(cyBle_flashStorage));

It is messy, not efficient, but quick solution..

Kind Regards,

Linas

0 Likes
FrSt_4749731
New Contributor II

Hello Linas,

Thank you for this information. I am trying to make the same approach on my side, but its not working. The PROVIDE() is always removed from the cycodeshareimport.ld file when I recompile it and I have turned Code generation to off. Did I miss something here?

Is function drv_flash_write defined by your team? Because I cant find it, so I will just use ordinary memcpy.

Thanks for the answer, Frenk

0 Likes
LiSi_1648326
New Contributor II

Hi Frenk,

You don't miss anything here. We have created a post build script to automatically add PROVIDE to the .ld file to solve this.

Function drv_flash_write is developed by us, it is basically calling CyBLE_Nvram_Write function.

Memcpy should not work, because the bonding is stored in flash, not ram.

Kind Regards,

Linas