Revision | Change Decription | Date |
---|---|---|
1.0 | Initial | 06/22/14 |
1.1 | Added Aligned Memory Accesses | 10/28/14 |
Hello Community Members,
This BLOG should be used as a "guide" for examining the Memory Map configurations and Application Development.
This is a compilation of Memory Map questions and answers from several of our forum users and I thank you for your questions and answers.
The Memory Architecture consists of both RAM and ROM with external EEPROM in the BCM20732/36/37 devices.
The Memory Architecture of the BCM20732S/36S/37S consists of the RAM and ROM with Internal EEPROM.
ROM vs. RAM application assignment has caused some confusion in the past, so we eliminated this nomenclature in SDK 2.0.1.
The ROM contains:
GATT:
ROM applications typically has some part of the application in the ROM and whatever user writes adds functionality to the ROM code
Application code is loaded in to NVRAM
RAM apps use LE Stack in the ROM
NVRAM:
Let's take an example from ws_upgrade.c in [uart|ota]_firmware_upgrade sample app from SDK 2.0.1
Note: If you increase DLConfigVSLength, you may have to also increase ConfigDSLocation (which is the same as DS1 in the picture above) so that there is no overlap (the hex file conversion step when building will fail if it detects an overlap between the two regions).
Serial FLASH:
Serial Flash images are not compressed (because SF reads has only ~3% overhead and decompressing will make it slower).
BCM20736 will not access more than ~128kbytes from the base but the API uses 24 bit addresses (serial flashes use 24 bit addresses), so the entire SF should be accessible
The virtual addresses used by the FW API for EEPROM and SF is different
0xFF000000 for EEPROM and 0xF8000000 for Serial FLASH
These offsets should be used with bleappfwu_*().
PATCHES:
Patches take up 1900 bytes (today) assuming you only want the mandatory patches (no extra features that are being patched in).
So your application space gets ~28K (today)
MEMORY ARCHITECTURE BLOCK DIAGRAM:
Let's start with a Memory Map Diagram of the BCM20732:
The 30K is shared memory (between patches and the app) and the dynamically allocated buffers also take up some of this space.
The ‘total RAM footprint ‘ line at the end of the build is only the static portion of the app + patches (includes code + initialized and uninitialized data) in our flat memory model.
So you cannot take the app start address and add the app size and then subtract from 60K to get remaining size
The 4K CM3 Mapper is for the Cortex M3 Memory Map for Interrupts Stack, etc.
Note that our Stack (YELLOW) is 30K and is DATA ONLY.
The Patches Section (Features,Updates, etc) is combined with the User App but:
Static variables that are NOT initialized end up in the data area:
SDK 2.0 Hello_Sensor Example App:
As an example, we take the Hello_Senor App and using the SDK Console Window, we see the Patches Start/End Addresses:
The Patches and Application Start Addresses are listed below:
As you can see, there is overlap between Patches and Beginning of Application
So after the Patches are finished loaded, a portion of the RAM is available for the Application
Here is what is happening:
Question – How much memory do you have?
Notes:
The NVRAM has a lot of headers.
Serial FLASH is similar 0 – 4K
Questions:
Q: In the first diagram it suggests that the maximum size of an app should be 26K?
A: 26K is a good approximation because it really depends on what (HW/drivers/features) the app initializes and uses. cfa_mm_MemFreeBytes() is the ultimate authority on the amount of RAM available
Q: Is there any way to estimate the amount needed for 'dynamic allocation' in that first diagram?
A: Not really, this is allocated for OS buffers, TX and RX buffers, stack buffer pools, thread stacks, callback registrations etc.
Q: If I end up with a total ram footprint of 26K , I am nervous that I might get overruns?
A: Yes
Q: What is the maximum stack size?
A: The app thread stack size is 1K (1024 bytes).
Q: What is the amount of space available for global and static variables?
A: The app code + globals (initialized and zero-initialized) all share the same space. So allocating more globals will reduce space for app code and vice-versa.
Q: Are there any built in functions of the stack that can be turned off to save space, for example if I disable the battery status profile does that cut down on the footprint?
A: No, here's why
Disabling battery monitor will not give you more space because its in the ROM.
This BLOG should get you going and I will be adding more later.
Additions:
The CPU core is an ARM Cortex M3 which supports unaligned accesses (so no exceptions will be thrown).
However, there is a performance penalty - the instruction will take multiple cycles to complete and the pipeline will stall (see ARM documentation). Load/Store multiple instructions do not support unaligned accesses.
Thanks
JT
Show LessThis BLOG is a short introduction for configuring the TAG3 board for use with the Serial FLASH.
This information is taken from our TAG3 document Manual : The specified document was not found. and our Quick Start Guide The specified document was not found.
1. The TAG3 board contains a Serial FLASH device and can be configured with a few resistor modifications and additions:
See the TAG3 Board below:
2. TAG3 Board Assembly displaying the resistor installation/modifications for the on board Serial FLASH:
3. The table below defines the resistors to configure the Serial FLASH:
4. You will need to place the SW4 switches 5,6,7,8 in the OFF position (They are actually show in the ON Position in this photo):
5. In the SDK you will need to modify your Make Target to include NV=SFLASH:
Note: In this case we have used COM Port 21 as observed in our Windows Device Manager:
5. Using the Recovery Procedure from the The specified document was not found. document, your recovering console message should look like the following:
A few extra notes about Serial FLASH:
You will need to use the same Macronix Serial Flash that is supported by the ROM and ships on the TAG3 board. Please see the schematic snippet below:
The Macronix MX25U4033 device works as well if you needed a second option.
Please see the notes below:
MX25U4033: https://www.macronix.com/en-us/products/NOR-Flash/Serial-NOR-Flash/Pages/spec.aspx?p=MX25U4033E&m=Serial%20NOR%20Flash&n… (good for new designs)
MX25U4035: https://www.macronix.com/en-us/products/NOR-Flash/Serial-NOR-Flash/Pages/spec.aspx?p=MX25U4035&m=Serial%20NOR%20Flash&n=… (not recommended for new designs)
Regarding the two different Flash PNs, here’s a document from the Macronix website that compares the two:
https://www.macronix.com/Lists/ApplicationNote/Attachments/1872/AN126V1_MX25U4035%20to%204033E.pdf
Show LessProduct Selection | Product Evaluation | WICED Sense | Product Development | Manufacturing / Production |
The following WICED Smart BCM2073X Coding Tips were a contribution from one of our BLE power users, maxsong
A special thanks go out to Max for sharing this material he generated with the community.
WICED Smart BCM92073X EEPROM and SFLASH Layout
WICED Smart BCM92073X OTA Firmware Upgrade (1 of 2)
WICED Smart BCM92073X OTA Firmware Upgrade (2 of 2)
WICED Smart BCM92073X I2C EEPROM Emulation Porting Guide
WICED Smart BCM92073X NVRAM Access
WICED Smart BCM92073X GATT DB Operation
Show Less