Usage of SNV area for user custom parameters ( CC26xx)

JXS,

Can you please clarify to my queries, mentioned above!

thanks.
Anil

Hello Svend,
I still see some open points which are in my view not addressed from Anil's message:
- Can the SNV used simultaneously for storing bonding keys AND user parameters?
- In such case, is any of the positions between 0x80 to 0x8F always safe to save user parameters? Then, where are the Bonding keys stored? They will never collide/corrupt each other?
- How much space is used by bonding with 1 device?

Thank you in advance.

user4388057 said:

Can the SNV used simultaneously for storing bonding keys AND user parameters?

Yes.

user4388057 said:

In such case, is any of the positions between 0x80 to 0x8F always safe to save user parameters? Then, where are the Bonding keys stored? They will never collide/corrupt each other?

They are both stored in the SNV area but the ID is used  to ensure they don't overwrite / corrupt each other. 

The way the SNV driver works is that you write your data together with an ID to the SNV area which. You can write data with the same ID multiple times (all SNV entries are stored sequentially in the SNV area) and when you read the most recent written data corresponding to your ID will be returned.

user4388057 said:

How much space is used by bonding with 1 device?

I am not entirely sure, JXS might be able to respond to that. The stack has reserved space for up to 10 bonded devices.

Regards,
Svend

Svend,

Thanks for your explanation.

Can you please tell me how much space is allocated to user and for bonding keys storage in 4k page?? I want to know from where(offset address in flash page) the user ID's 0x80-0x8F will be stored in given 4k page?

And one more thing to clear is, you were mentioning the ID's from 0x80-0x8F, in such case if i need to use all the ID's instead of one then what is the limitation on storing the data bytes for the each ID mentioned ( I think first we should know how much space you were allocating for user and then internal handling of user ID's, PLEASE, I NEED SOME DOCUMENTATION ON THIS TO UNDERSTAND YOUR SNV DRIVER, CAN YOU PLEASE ROUTE TO EXACT LOCATION WHERE I CAN FIND SOME ).

Atleast, in case if we use only one ID in our Application to store user information, can you please tell me what maximum number of bytes we can store for one(ID) transaction?

many thanks for your kind support.

You have 4kB that is shared for both bonding information and user data, there are no separate allocation for application data and bonding data.They are as previously mentioned stored sequentially in the page once they are written in, meaning you have no control of where in the page the data is located.

As you can find in the BLE software developers user guide, you will see the the length field in the API is osalSnvLen_t. This is again found in your project as a 8 bit unsigned integer, meaning max length is 255 bytes.

We provide the driver API with documentation, if you need to understand the internals of the SNV driver I suggest you open the stack and read the code. A good starting point is osal_snv_wrapper.c.

Regards,
Svend

Hello Svend,

I don't think you suggestion to read the source code of the TI BLE Stack is correct. We don't need to understand how the BLE Stack works (as long as it works), but we need to understand how to use it. The documentation about the SNV is in my view really poor and not enough.

As a software developer and user of the TI BLE stack, I expect to be able to use it by reading the documentation carefully. Am I missing any specific document explaining it? In the SW Developers guide there is approximately 1 page dedicated to it. The return values of the write operation are only "Success" or "Failure" without further detail. The last part of this section suggests me even more uncertainty:

Since SNV is shared with other modules in the BLE SDK such as the GapBondMgr, it is necessary to carefully manage the NV item ID’s. By default, the ID’s available to the customer are defined in bcomdef.h:

// 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

"This must match the number of Bonding entries" -> Must match?? How do we match it?

Are we allowed to change the ID numbers? But if each ID has max 256bytes and in this range there are 16 addresses, the total is the full 4KB. So how does this work?

Thank you for your kind support.

Hi,

If you need more information than the API and which ID's to use you would have to read the code.

In the file "bcomdef.h" that you reference you will find the full set of ID's used by the BLE stack:

// 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

// 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

As you see the stack will use other ID's for the bonding information etc. The comment "This must match the number of Bonding entries" is probably incorrect.

In the NV RAM, a single bonding entry consist of (referenced from gapbondmgr.c) : 

* A single bonding entry consists of 6 components (NV items):
* Bond Record - defined as gapBondRec_t and uses GAP_BOND_REC_ID_OFFSET for an NV ID
* local LTK Info - defined as gapBondLTK_t and uses GAP_BOND_LOCAL_LTK_OFFSET for an NV ID
* device LTK Info - defined as gapBondLTK_t and uses GAP_BOND_DEV_LTK_OFFSET for an NV ID
* device IRK - defined as "uint8 devIRK[KEYLEN]" and uses GAP_BOND_DEV_IRK_OFFSET for an NV ID
* device CSRK - defined as "uint8 devCSRK[KEYLEN]" and uses GAP_BOND_DEV_CSRK_OFFSET for an NV ID
* device Sign Counter - defined as a uint32 and uses GAP_BOND_DEV_SIGN_COUNTER_OFFSET for an NV ID

Summing these together using the default settings and assuming the compiler packs the data:

• Bond Record: 4 bytes
• local LTK Info: 27 bytes
• device LTK Info: 27 bytes
• device IRK: 16 bytes
• device CSRK: 16  bytes
• device Sign Counter: 4 bytes

Ideally you should have 94 bytes per bonding record, in practice probably a few more due to byte alignment.

Hello Svend,

It is the same person who was making the questions, I just changed my username by something more personal :-D

Thanks again for your answer, it is helping very much.

Regarding your mention: "The comment "This must match the number of Bonding entries" is probably incorrect.". I would recommend that you clarify this point with the person in TI who made this documentation and change it in the next documentation release. We need however, as soon as possible, a confirmation that this documentation is "incorrect" or not.

We need to understand these 2 sentences:
// Bonding NV Items - Range 0x20 - 0x5F - This allows for 10 bondings
// Customer NV Items - Range 0x80 - 0x8F - This must match the number of Bonding entries

Could you make an example how these 2 SNV areas interact with each other? i.e. If there is 1 bonded device, can we still use the full 0x80 to 0x8F? What if we have 2, 3 or 10 bonded devices?

0x80 to 0x8F = 16 IDs. Each ID can store 256bytes (right?). 16 * 256 bytes = 4096 bytes = total space for SNV. So it seems not reasonable that we can still use any ID independently of the number of bonded devices.

I hope you can understand my concerns.