13 Replies Latest reply on Sep 24, 2014 10:00 PM by ArvindS_76

    nvram: number of locations to write to

    michaelnelson

      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

        • 1. Re: nvram: number of locations to write to
          MichaelF_56

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

          • 2. Re: nvram: number of locations to write to
            michaelnelson

            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.

            • 3. Re: nvram: number of locations to write to
              michaelnelson

              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.

              • 4. Re: nvram: number of locations to write to
                ArvindS_76

                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.

                1 of 1 people found this helpful
                • 5. Re: nvram: number of locations to write to
                  michaelnelson

                  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

                  • 6. Re: nvram: number of locations to write to
                    ArvindS_76

                    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.

                    • 7. Re: nvram: number of locations to write to
                      michaelnelson

                      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

                      • 8. Re: nvram: number of locations to write to
                        ArvindS_76

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

                        • 9. Re: nvram: number of locations to write to
                          michaelnelson

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

                          • 10. Re: nvram: number of locations to write to
                            OceanS_76

                            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?

                            • 12. Re: nvram: number of locations to write to
                              MudeL_51

                              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?

                              • 13. Re: nvram: number of locations to write to
                                ArvindS_76

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

                                1 of 1 people found this helpful