GAP_BOND_MGR and Pairing

Hello,

Disabling GAP_BOND_MGR will disable Pairing as well. If you disable SNV (NO_OSAL_SNV) but leave bonding enabled, you may experience undefined results if you attempt Pairing with bonding.

Best wishes

I was hoping that bonding and pairing would be treated as 2 separate things. Anyway, I tried setting OSAL_SNV=1 and the application doesn't seem to work at all after that, is this a known issue?

I have external flash, is it possible to replace OSLA_SNV with a driver to use external memory? If so are there any examples of this?

If you change OSAL_SNV you need to compile both the application and stack again to let the stack post-build Boundary.exe tool set new RAM/Flash boundaries before linking.

It should be fully possible to replace the SNV driver with a custom one. osal_snv_wrapper.c (stack project) would be the place to start out as well as modifying the stack linker file cc26xx_ble_stack.icf (IAR). The "FLASH_ROM_BUILD" (BLE stack split between Flash and ROM) is the one you need to look at in the linker file.

Regards,
Svend

I did clean builds of both the stack and application multiple times and made sure the boundaries were updated correctly, I did this atleast 5 times. It might be worthwhile to verify that there with SimpleBLEPeripheral using CCS.

Hello,

Setting OSAL_SNV=1 requires a patch for CCS builds. This has been corrected in our upcoming Stack update, but for now you can apply the patch to your 2.0 SDK installation:

In nvocop.c, change:
uint8 NV_FLASH[FLASH_PAGE_SIZE];
To
const uint8 NV_FLASH[FLASH_PAGE_SIZE] = {0x00};

Sorry for not pointing that out sooner.

Best wishes

That worked, thanks!

Are you able to give a rough timeframe for the next release? I'm waiting for another fix to the MAX_PDU_SIZE problem as well.

I just looked at this again. To summarise, I want to require pairing (i.e. entering passcode) but don't need bonding, this is a data logger that will only be visited 3 or 4 times a year, I also want the BTLE stack to be as small as possible. 

As a quick test I changed osal_snv_wrapper.c to do nothing (see code below) and this seems to work the way I want it to and reduces the stack size by 8K. I am just wondering if this code is ok or is it a hack that will have side effects? I don't know how the stack uses SNV so it's hard for me to tell.

uint8 osal_snv_init( void )
{
    return NVINTF_SUCCESS;
}

uint8 osal_snv_read( osalSnvId_t id, osalSnvLen_t len, void *pBuf)
{
    return NVINTF_FAILURE;
}

uint8 osal_snv_write( osalSnvId_t id, osalSnvLen_t len, void *pBuf)
{
    return NVINTF_SUCCESS;
}

uint8 osal_snv_compact( uint8 threshold )
{
    return NVINTF_SUCCESS;
}

I don't see a reason why it would not work as long as you:
- Compile out the bond manager when building the stack (Comment out -DGAP_BOND_MGR from buildConfig.opt in stack project).
- Do not use the SNV API yourself.

That takes me back to where I started. If you look at the first answer above, disabling the bond manager also turns off pairing which is confusing to me but I'm not an expert on Bluetooth so maybe it has to be that way.

So if I leave the bond manager enabled and hack out the SNV as above so the bond manager thinks it's storing keys, and when it tries to retrieve the bond information it finds nothing (which would simulate the first time it pairs with a device I think?) will that work ok?

Good point, I need to start reading the full thread..
Aslak N. might hopefully have some suggestions.

Hi,

Your method should probably work. But please note that we have not tested this.

That said, all the accesses to SNV are in open source code, so you can verify the behavior is as expected yourself.

Best regards,
Aslak

Hello,

With BLE-Stack 2.1 now available, you can exclude the GATT Client from your peripheral builds (default for SimpleBLEPeripheral), which will save you ~ 4kB of flash.

If you are blocking SNV storage, you should update your GAPBOND_BONDING_ENABLED value to FALSE to indicate that the Stack does not support Bonding.

Best wishes