Excess pairings over 10 are not stored (bond table is full). You will enter a successful connection.
In the bond manager when a new bond is to be stored, if bondIdx in the below code snippet is equal to GAP_BONDINGS_MAX then the bond will not be stored and the next time you connect you will have to repeat the pairing process over again.
// First see if we already have an existing bond for this device
bondIdx = gapBondMgrFindAddr( pBondRec->publicAddr );
if ( bondIdx >= GAP_BONDINGS_MAX )
{
bondIdx = gapBondMgrFindEmpty();
}
from https://e2e.ti.com/support/wireless_connectivity/f/538/t/388554
The white list for CC2540 and CC2541 has a maximum of 8 entries.
https://e2e.ti.com/support/wireless_connectivity/f/538/p/182903/1111969#1111969
Other Bluetooth connection limitation issue:
http://superuser.com/questions/332767/limit-to-the-number-of-devices-that-can-be-paired-with-a-bluetooth-device
Sony up to nine:
https://us.en.kb.sony.com/app/answers/detail/a_id/39047/~/what-is-the-maximum-number-of-bluetooth-wireless-devices-that-can-be-paired%3F
Provide some solution for fix the probelm.
such as FIFO loop to saving Key.
https://e2e.ti.com/support/wireless_connectivity/f/538/p/458133/1654011
bcomdef.h
/** @defgroup BLE_NV_IDS BLE Non-volatile IDs
* @{
*/
// Device NV Items - Range 0 - 0x1F
#define BLE_NVID_IRK 0x02 //!< The Device's IRK
#define BLE_NVID_CSRK 0x03 //!< The Device's CSRK
#define BLE_NVID_SIGNCOUNTER 0x04 //!< The Device's Sign Counter
// Bonding NV Items - Range 0x20 - 0x5F - This allows for 10 bondings
#define BLE_NVID_GAP_BOND_START 0x20 //!< Start of the GAP Bond Manager's NV IDs
#define BLE_NVID_GAP_BOND_END 0x5f //!< End of the GAP Bond Manager's NV IDs Range
// GATT Configuration NV Items - Range 0x70 - 0x79 - This must match the number of Bonding entries
#define BLE_NVID_GATT_CFG_START 0x70 //!< Start of the GATT Configuration NV IDs
#define BLE_NVID_GATT_CFG_END 0x79 //!< End of the GATT Configuration NV IDs
//----------could add for saving counter to deal with FIFO bonding info
// Customer NV Items - Range 0x80 - 0x8F - This must match the number of Bonding entries
#define BLE_NVID_CUST_START 0x80 //!< Start of the Customer's NV IDs
#define BLE_NVID_CUST_END 0x8F //!< End of the Customer's NV IDs
/** @} End BLE_NV_IDS */
ti_51ew_cc2540b.xcl
// Internal flash used for NV address space.
// ---------------------------
//
// Address range for HAL_FLASH_PAGE_SIZE == 2048
-D_BLENV_ADDRESS_SPACE_START=0x7E800
-D_BLENV_ADDRESS_SPACE_END=0x7F7FF
//
// Address range for HAL_FLASH_PAGE_SIZE == 4096
//-D_BLENV_ADDRESS_SPACE_START=0x7D000
//-D_BLENV_ADDRESS_SPACE_END=0x7EFFF
http://www.deyisupport.com/question_answer/wireless_connectivity/bluetooth/f/103/t/48352.aspx
注意下面的表述，也就是说2K，1K存数据，另1K是做备份。
The main reason for SNV is that it's only possible to erase a page, and not a small area of flash. As you re-write a SNV data item, the SNV will create a new space for it and write it. The old space will be marked as invalid, and will become free again when that page is erased. There is only one active page and then a mirror page where the valid items are copied to when the page gets full. I think the max size for everything in SNV is 1K (minus about 250K for bonding info).
How to implement saving FIFO bonding info to unlimit GAP_BONDINGS_LIMIT 10, could refer the above URL.
It add counter by using BLE_NVID_CUST_START to record the FIFO index, but it suggests to implement in the connection_terminate. I think it will have problem if bonding done at connection, you will never do the FIFO counter if power off the device before terminate connection event does.
Another way is add main.c to check bonding if full then clear one space for next bonding process. By this way, could add bonding counter to handle this.
There are some important considerations when using this API:
1. These are blocking function calls and an operation may take several milliseconds to complete. This is
especially true for NV write operations. In addition, interrupts may be disabled for several milliseconds. It
is best to execute these functions at times when they do not conflict with other timing-critical operations.
For example, a good time to write NV items would be when the receiver is turned off.
2. Try to perform NV writes infrequently. It takes time and power; also most flash devices have a limited
number of erase cycles.
3. If the structure of one or more NV items changes, especially when upgrading from one version of a TI
stack software to another, it is necessary to erase and re-initialize the NV memory. Otherwise, read and
write operations on NV items that changed will fail or produce erroneous results.
沒有留言:
張貼留言