BCM20732S NVRAM Size

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

How much NVRAM do we have access to?  In MMP920732SW-AN102-D1 it states that we can specify an ID from 0x10 to 0x6F with maximum block size of 255 bytes.  Does this mean that we have ((0x6F - 0x10) * 255 bytes) = 24225 bytes?  Do we need to be concerned about frequently read/writing from the same ID?

0 Likes
1 Solution

There are a couple of limits here. The first one is that you can use IDs between 0x00 and 0x6F and each item is limited to 255 bytes (fragment larger items into multiple items with different IDs). The second limit is with what is called the Volatile Section (or VS) that is programmed into the EEPROM. This space is reserved for the stack to store all pairing information (each pairing info requires under ~200 bytes) and the application's data with these IDs. With SDK 1.1.0, this is 512 bytes and with SDK 2.0.1, this was increased to 1024 bytes.You can change this if you like for you application by modifying the following values in <SDK>/Platforms/BCM92073*TAG_Q32/2073*_EEPROM.btp (or the 2073*_SFLASH.btp) file:

DLConfigVSLength - length of this volatile section.

ConfigDSLocation - location of the application code and data (also known as DS).;

Note that the VS and DS areas cannot overlap. For the layout in the EEPROM or SF, see comments in ws_upgrade.c in the SDK (1.1.0 or 2.0) and so if you want to support field upgrades (OTA or uart or other mechanisms), you have to move these sections appropriately.

> Do we need to be concerned about frequently read/writing from the same ID?

Yes, to some extent. EEPROM and Serial Flash parts have a typical write/erase cycle limit (or mean time to failure) of the order of 100,000 cycles. With an EEPROM, writing the same ID with same length as before will overwrite the item. With SF or when the length is different, the item at the old offset will be marked as unused and the item will be appended to the end of the section as a new item (so potentially creating a hole in the NV). After multiple cycles of this, FW will consolidate (or defragment) the NV so all the holes are filled by valid items and free space is at the end of the section.

View solution in original post

8 Replies
Anonymous
Not applicable

I think the total size of NRVRAM is 255 bytes even there are 95 IDs.

0 Likes
Anonymous
Not applicable

I also would like to know how much size of NVRAM can be used by application.

Does anybody know about this?

0 Likes

There are a couple of limits here. The first one is that you can use IDs between 0x00 and 0x6F and each item is limited to 255 bytes (fragment larger items into multiple items with different IDs). The second limit is with what is called the Volatile Section (or VS) that is programmed into the EEPROM. This space is reserved for the stack to store all pairing information (each pairing info requires under ~200 bytes) and the application's data with these IDs. With SDK 1.1.0, this is 512 bytes and with SDK 2.0.1, this was increased to 1024 bytes.You can change this if you like for you application by modifying the following values in <SDK>/Platforms/BCM92073*TAG_Q32/2073*_EEPROM.btp (or the 2073*_SFLASH.btp) file:

DLConfigVSLength - length of this volatile section.

ConfigDSLocation - location of the application code and data (also known as DS).;

Note that the VS and DS areas cannot overlap. For the layout in the EEPROM or SF, see comments in ws_upgrade.c in the SDK (1.1.0 or 2.0) and so if you want to support field upgrades (OTA or uart or other mechanisms), you have to move these sections appropriately.

> Do we need to be concerned about frequently read/writing from the same ID?

Yes, to some extent. EEPROM and Serial Flash parts have a typical write/erase cycle limit (or mean time to failure) of the order of 100,000 cycles. With an EEPROM, writing the same ID with same length as before will overwrite the item. With SF or when the length is different, the item at the old offset will be marked as unused and the item will be appended to the end of the section as a new item (so potentially creating a hole in the NV). After multiple cycles of this, FW will consolidate (or defragment) the NV so all the holes are filled by valid items and free space is at the end of the section.

SuLe_1710756
Level 5
Level 5
10 likes received First like received First like given

Hi arvinds,

I understand what you said, but I still have some questions about NVRAM size and its layout.

As you said, IDs are 0x00 ~ 0x6F and each item is limited to 255 bytes.

1) Even if customer wants to use 128KB EEPROM in order to extend user data(VS),

   DLConfigVSLength in 20736_EEPROM.btp can't be exceeded 28,560((0x00~0x6F) * 255bytes). Right?

2) If customer uses 128KB EEPROM, is it possible to use from ID 0x70?

3) As I know, SS2 and DS2 in EEPROM is for f/w upgrade. If customer would not provide f/w upgrade, SS2 and DS2 are not necessary as follow, right? Or SS2 and DS2 are always necessary regardless of f/w upgrade?

   -----------------------------------------------------------------------------------------------

   |  SS (256B @ 0)  | VS (1024B @ 0x100)  | DS (62KB @ 0x500)  |

   -----------------------------------------------------------------------------------------------

4) Each config values of 20736_EEPROM.btp are configured as follows,

   DLConfigVSOffset = 0

   ConfigDSLocation = 1408 // 0x580

   DLConfigSSLocation = 0

   DLConfigIncludeBTWSecurityKey = 0

   DLConfigVSLocation = 320 // 0x140

   DLConfigVSLength = 1024

   However, there are no information about SS2 and DS2 in the *.btp. How are their location configured like this?

   If customer wants to configure like this below, how we should change the configure values in the *.btp?

   ------------------------------------------------------------------------------------------------------------------------------------------------------------------------

   | SS1(256B @ 0)| SS2 (256B @ 0x100) | VS1(1024B @ 0x140) | DS1 (30.5KB @ 0x580) | DS2 (30.5KB @ 0x8000) |

   ------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Thanks,

SM

0 Likes
Anonymous
Not applicable

1) No. It can't be exceeded I think.

2) Please refer below thread.

BCM20732 EEPROM/SPI maximum supported size

0 Likes

> Even if customer wants to use 128KB EEPROM in order to extend user data(VS)....

Yes, this is correct. Also note that an EEPROM uses 16 bit addresses and so and so cannot be larger than 64Kbytes. Some vendors do have 128KByte parts, but they use different slave addresses for the lower and upper 64KBytes. The 2073x ROM cannot access the upper 64Kbytes for app/patch/configuration data. None of the bleprofile_*NVRAM API can access the upper 64K either. However, there is nothing in the firmware that prevents the app from using the upper 64K using the I2C or EEPROM drivers to access it.

> If customer uses 128KB EEPROM, is it possible to use from ID 0x70

NV item IDs have nothing to do with the NV size. All items over 0x6F are reserved, so you should not use it.

> As I know, SS2 and DS2 in EEPROM is for f/w upgrade.....

Yes, this is true. If you do not want to upgrade the app in the field (using any mechanism - uart/SPI/over the air), then you don't need these and you can use this space however you want.

> Each config values of 20736_EEPROM.btp are configured as follows,

The btp configuration seems to be configured exactly the way you want it to be.

The .btp file only has SS1, VS1 (VS2 is always implied, and applicable only for serial flash - see ws_upgrade.c for explanation) and DS1 information. SS2 and DS2 are always configured in ws_upgrade.c and there is no equivalent in the .btp file.

ZhaohuaS_76
Employee
Employee
25 sign-ins 10 questions asked 10 sign-ins

Hi arvinds,

Per you said each pairing info requires under ~200 bytes, could you describe which IDs were used to saving the pairing info?

0 Likes

You don't want to use anything over 0x70 because the stack uses some of these.

0 Likes