cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Smart Bluetooth

Anonymous
Not applicable

When using the bleprofile_WriteNVRAM write command, I can only write to 28 NVRAM Ids

Example:

If I start writing at ID 0x10, my last valid write is at location 0x2b.  I can't write out past that NVRAM ID. ID 0x2c Fails.

If I start writing at ID 0x30, my last valid write is at location 0x4b.  I can't write out past that NVRAM ID. ID 0x4c Fails.

Is this a limitation?

Is there a setting that allows me to write all IDs between 0x00 and 0x6F?

Thanks,

Mike

0 Likes
1 Solution
ArvindS_76
Employee

The default size of the VS section (where these are stored) is 1024 bytes in SDK 2.x. Did you change it to a larger size? Find the .btp file under Platforms/BCM92073XTAG_Q32/2073X_<PLATFORM_NV>.btp:

DLConfigVSLength = 1024

Change this to fit as many items you need to write into this area. You may have to move ConfigDSLocation too so it does not overlap. See ws_upgrade.c for an example of the layout.

View solution in original post

13 Replies
MichaelF_56
Moderator
Moderator

I believe arvinds addressed a similar question here in this discussion: BCM20732S NVRAM Size

0 Likes
Anonymous
Not applicable

The link you provided me is not the problem.

The problem is not where the data is stored; but the number of NVRAM IDs I can use.

I can only use 28 of them, regardless of which of the 28 IDs they are.

0 Likes
Anonymous
Not applicable

One other note:

The 28 NVNAM IDs I write to, don't have to be contiguous.

I can write to every 3rd ID without a problem (up to 28 of them);

But once I write over the 28 IDs, I have a problem.

0 Likes
ArvindS_76
Employee

The default size of the VS section (where these are stored) is 1024 bytes in SDK 2.x. Did you change it to a larger size? Find the .btp file under Platforms/BCM92073XTAG_Q32/2073X_<PLATFORM_NV>.btp:

DLConfigVSLength = 1024

Change this to fit as many items you need to write into this area. You may have to move ConfigDSLocation too so it does not overlap. See ws_upgrade.c for an example of the layout.

View solution in original post

Anonymous
Not applicable

In my test, I just wrote 1 byte to each location.

I was only able to write to 28 locations.

I am not sure how writing 28 bytes maps into the 1024 bytes defined by DLConfigVSLength.

Now I understand that these are written in 255 byte blocks.

Which means with 1024 bytes, I should only be able to write to 4 NVRAM IDs.

In either case, 28 writes divided by 1024 is 36 byte blocks (which doesn't make since).

Also, as I noted above, these 28 IDs I write to, does not have to be contiguous.

I wrote to 0x10, 0x13, 0x16, ... 0x5E, 0x61; It wrote just fine.

But when I wrote to the 29th ID 0x64, If failed.

I can just keep adjusting values, but I need to understand what is going on here, so I can set it to the correct size.

-Mike

0 Likes
ArvindS_76
Employee

The max size of an item is 255 bytes and when it is smaller than this it will not take up all the space. However, there is an overhead for each stored item and they are allocated/written to in pages (that don't necessarily correspond to the NV storage part's concept of pages). So when you write a 1 byte item, it is a bit bigger than this.

0 Likes
Anonymous
Not applicable

So, are you saying that if the  DLConfigVSLength = 1024 (bytes)

and since there are 0x00 to 0x70 NVRAM IDs, that the 1024 bytes are divided up into the 112 NVRAM IDs. approximately 9 bytes each, if you use all available NVRAM IDs.

And In my test case, where I was only writing 1 byte out for each NVRAM ID I used, that is took up 36 bytes, which is what allowed me to only write out to 28 NVRAM IDs.  (28*36=1008).

If the above is the case, then is the data stored with each NVRAM ID, random in length, as long as it does not exceed 255 bytes?

Also if there is a fix overhead size with each NVRAM ID that I can be provide with, then I can calculate how large to set the DLConfigVSLength to accommodate the data I wish to store.

-Mike

0 Likes
ArvindS_76
Employee

> So, are you saying that if the  DLConfigVSLength = 1024 (bytes)

and since there are 0x00 to 0x70 NVRAM IDs, that the 1024 bytes are divided up into the 112 NVRAM IDs. approximately 9 bytes each, if you use all available NVRAM IDs.

No. It does not work this way either. Think of it as a file system which requires a table of contents (the larger the VS section is, the larger the ToC will be). To keep fragmentation to a minimum, you allocate an integer number of pages to every item. Each page is 32 bytes long. There is a 3 byte overhead per item. If your item takes 1 byte, the items is 4 bytes long, but will take up the entire 32 byte page. The next item will start at the next page. If you item is 30 bytes long, it will get 2 pages because the header needs to be stored with it too. The FW requires some more pages to store its short term and long term keys. The FW requires some pages for book-keeping (so it can defragment when it needs contiguous pages for a new item). So with 1024 bytes of VS, you can have 32 pages. The FW took 4 pages leaving you 28. You wrote to all 28 pages with 1 byte data leaving no space for the 29th.

Anonymous
Not applicable

So data is written in 32byte blocks + some overhead, that is what I was looking for.

0 Likes
ZhaohuaS_76
Employee

Hi arvinds,

Per you said, BLE stack divided NVRAM to many pages, one page have 32 bytes, is it same on SDK 1.x and SDK 2.x?

0 Likes
ArvindS_76
Employee

Yes, it is.

0 Likes
MudeL_51
Employee

Hi Arvinds,

As you said, there is a 3 bytes header in each page.

I guess that the header is like [VS ID] [Data Length] [Next Page]:

A> 1 byte [VS ID], and the most significan bit (Bit 7) of [VS ID] is used as a flag to indicate this page is used or not, as its rang is 0 - 0x7F.

B> 1 byte [Data Length], the max item length is 255.

C> 1 byte [Next Page] which is linked to another page if this item need more than one page.

Does the design look like that?

0 Likes
ArvindS_76
Employee

Its 3 byte header per item (not per page). The third byte is a checksum.