RevisionChange DecriptionDate1.0Initial06/22/141.1Added Aligned Memory Accesses10/28/14Hello Community Members,This BLOG should be used as a "guide" f...
Added Aligned Memory Accesses
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:
Embedded BLE stack
L2CAP, GAP, GATT
BT_SIG approved profiles such as proximity, heart rate monitor, thermometer, blood pressure monitor and time
Drivers for I2C EEPROM, SPI EEPROM and SPI Serial flash
GATT database handles are 16 bit values from 0x00 to 0xFFFF
This limits you to ~65K entries in the database
With SDK 1.1.0, GATT characteristic length/max length is a 1 byte field
SDK 2.0.1, it could optionally be a 2 byte field too
The BT spec limits characteristics to a max of 512 bytes
You will hit the available RAM limit long before your database gets anywhere close to this
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
Let's take an example from ws_upgrade.c in [uart|ota]_firmware_upgrade sample app from SDK 2.0.1
When you read/write/delete NV items using bleprofile_*NVRAM, these operations are performed in the section marked VS1 in the picture above.
The stack uses some of this for some internal book-keeping
When you pair, all pairing information is stored in this area too
So it is possible that you ran out of space when you attempted to store the 63 remaining bytes
You can increase the the space allocated for VS1 by changing a couple of options in <SDK>/Platforms/BCM92073?TAG_Q32/2073?_EEPROM*.btp
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 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 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:
The Patches_Init Code is overlayed and can be used by the App after the Patches are loaded
The App_Init/BLE_SET_CONFIG is also overlayed by the Dynamic Allocation
Static variables that are NOT initialized end up in the data area:
The ‘Data ONLY’ area in yellow is the data area allocated by the BLE stack that’s in the ROM
So nothing new goes in here
All application data (RW and ZI) and application code (Code + RO) goes into the same region in the RAM
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:
Patches start at where the ROM finished 0x00204568
Patches end at 0x00204AFC, but the Application starts at 0x00204974 even before the Patches end
So there is an overlap.
Once the application ends at 0x00204C28, but dynamic allocation starts even before this.
The reason is that in the order in which we boot, The Patches get copied in first and they will get initialized.
Then the section of the code where there in Patch initialization, that will get reused and we will put the application on top of it and overlay the application.
Once the Patch Init code is running, we can replace that section with the application code.
We are re-using the RAM from the Boot Loader and Reusing the application initialization code also for dynamic allocation
Once we have initialized, we don/t need that code anymore.
The ROM boots and copies in ALL of the patches
And then it will run the Patch Init Code and installs all of the MANDATORY patches
Once that copy is done, you don’t need that Patch Init Code
The ROM will copy the Application on top of it.
Overwrite the Patch Init Code with Application Code
Application Code will be 1.7K of code or less.
The App calls the App Init Function and will say, available RAM is here
Then the ROM starts Dynamic Allocation from here
What goes in?
Buffer,xx, Stack Buffer Tools, and Data
Call Back Registrations
Dump the Stack on the Peripheral UART and reset
Question – How much memory do you have?
There is a function call CFG_MM_MemFreeBytes
This is a pointer that keeps moving at every step
When ROM finishes Initialization, available RAM is pointing to this
When PATCHES finish Initialization, available RAM is pointing to this
When the App finishes the Initialization, available RAM points to this area
We can find how much we need by making 2 calls to RAM:
By using init.c, we can take a snap shot of what this function returns and this will tell you where nm is at this point of time
At the end of your Application Create Function, you take another snapshot of this guy and the difference between these 2 is your dynamic allocation
The NVRAM has a lot of headers.
Serial FLASH is similar 0 – 4K
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?
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.
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.
If you are having problems with your installer, check that the download size of the installer is roughly 260MB, installer problems are typically caused by incomplete downloads.
The picture below shows a very common error message. Our SDK utilizes a 32-bit version of an Eclipse based IDE which requires a 32-bit version of JRE to be installed. If you already have the 64-bit JRE installed, you will also need to install the 32-bit version as well. The JRE is designed to allow both 32 and 64 bit variants to be installed on the system.
The WICED Sense kit uses a Silicon Labs USB to Serial Device. The TAG3 board uses an FTDI USB to Serial Device. Both should be installed as part of the SDK 2.2.1 installation process. If not, the FTDI drivers for the TAG3 reinstall them using the file /WICED-Smart-SDK/Drivers/dpinst.exe (make sure you access from the command line). The Silicon Labs USB Drivers can be foundWICED Sense Table of Contents
Everything we have for the WICED Sense, such as schematics, drivers, and Android application source code, can be accessed through theWICED Sense Table of Contents. A great post for the WICED Sense is theWICED SENSE Kit BLOGwhich is like a WICED Sense quick start guide.
Some Android devices appear to have issues pairing to the WICED Sense Tag from inside the app, linked is a work-around that should allow you to connect to your Android device:WICED Sense Android Pairing Work-Around