BCM2073x SoC requires external NVRAM to store an application program.
BCM2073xS SiP module contains internal EEPROM as the NVRAM.
So I think they point the same one (internal NVRAM or external EEPROM).
If you still have a question about it, please tell me the thread which makes you confused.
The EEPROM is commonly referred to as NVRAM.
In addition to the user application, EEPROM also includes BD ADDR (Bluetooth Device Address), Patches and Bonding/Pairing information.
When programming, the SDK essentially downloads a minidriver to RAM then pushes the code over the HCI uart to the minidriver which will then write it to out to EEPROM.
This process will also automatically load the application into available RAM, so a Bootloader is not needed.
What I'm confused is where eeprom and NVRAM are used for.
I'm using BCM20737 SoC.
If BCM2073X needs external EEPROM, does it mean BCM2073X does not contain NVRAM inside?
Then I have another questions about NVRAM ID.
Is NVRAM ID limited to be upto 0x70 in case that I use 1Mbit external EEPROM?
There is no NVRAM internal to the 2073X series, SOC or module.
There is 320K of ROM which contains Core firmware + embedded stack + profiles.
We also include 60K of RAM, of which about 25-30KB is used while running our stack; the other 30KB is available for customer app code and ROM patches if needed.
Regarding EEPROM limitations, both of these threads contain alot of useful information:
Note that the team has used larger 128KByte EEPROMs with the the BCM2073x, but only the lower 64KBytes will be used/accessed by the firmware.
On the other hand, the EEPROM driver API provides low level access to write to any EEPROM location, so the application can still use the upper 64KBytes by specifying a different I2C slave address than the one used for the lower 64KBytes, which is usually 0xA0/0xA1.
However, you cannot use this space to store app/patch code/configuration – only the apps own data using the raw EEPROM read/write API (note that none of the bleprofile_*NVRAM API will work with the upper 64K).
Note that the 16b/64k limitation is an EEPROM architecture issue more than a firmware related one. EEEPROMs always use 16 bit addresses, which limits their size to 64KBytes. The way EEPROM vendors work around this is to use a different slave address for the higher 64KBytes (so the same 16 bit address space is mapped to a physically different slave).