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

cross mob

BCM20732 Memory Map Architecture

BCM20732 Memory Map Architecture

Anonymous
Not applicable
RevisionChange DecriptionDate
1.0Initial06/22/14
1.1Added Aligned Memory Accesses10/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:

  1. Embedded BLE stack
  2. L2CAP, GAP, GATT
  3. BT_SIG approved profiles such as proximity, heart rate monitor, thermometer, blood pressure monitor and time
  4. SMP
  5. HCI
  6. Drivers for I2C EEPROM, SPI EEPROM and SPI Serial flash

GATT:

  1. GATT database handles are 16 bit values from 0x00 to 0xFFFF
  2. This limits you to ~65K entries in the database
  3. With SDK 1.1.0, GATT characteristic length/max length is a 1 byte field
  4. SDK 2.0.1, it could optionally be a 2 byte field too
  5. The BT spec limits characteristics to a max of 512 bytes
  6. 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

NVRAM:

Let's take an example from ws_upgrade.c in [uart|ota]_firmware_upgrade sample app from SDK 2.0.1

pastedImage_9.png

  1. When you read/write/delete NV items using bleprofile_*NVRAM, these operations are performed in the section marked VS1 in the picture above.
  2. The stack uses some of this for some internal book-keeping
  3. When you pair, all pairing information is stored in this area too
  4. So it is possible that you ran out of space when you attempted to store the 63 remaining bytes
  5. 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:

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:

pastedImage_0.png

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:

  1. The Patches_Init Code is overlayed and can be used by the App after the Patches are loaded
  2. 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:

  1. The ‘Data ONLY’ area in yellow is the data area allocated by the BLE stack that’s in the ROM
  2. So nothing new goes in here
  3. 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:

pastedImage_5.png

The Patches and Application Start Addresses are listed below:

pastedImage_9.png

pastedImage_18.png

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:

  1. Patches start at where the ROM finished 0x00204568
  2. Patches end at 0x00204AFC, but the Application starts at 0x00204974 even before the Patches end
  3. So there is an overlap.
  4. Once the application ends at 0x00204C28, but dynamic allocation starts even before this.
  5. The reason is that in the order in which we boot, The Patches get copied in first and they will get initialized.
  6. 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.
  7. Once the Patch Init code is running, we can replace that section with the application code.
  8. We are re-using the RAM from the Boot Loader and Reusing the application initialization code also for dynamic allocation
  9. Once we have initialized, we don/t need that code anymore.
  10. The ROM boots and copies in ALL of the patches
  11. And then it will run the Patch Init Code and installs all of the MANDATORY patches
  12. Once that copy is done, you don’t need that Patch Init Code
  13. The ROM will copy the Application on top of it.
  14. Overwrite the Patch Init Code with Application Code
  15. Application Code will be 1.7K of code or less.
  16. The App calls the App Init Function and will say, available RAM is here
  17. Then the ROM starts Dynamic Allocation from here
  18. What goes in?
  19. Buffer,xx, Stack Buffer Tools, and Data
  20. Call Back Registrations
  21. Dump the Stack on the Peripheral UART and reset

Question – How much memory do you have?

  1. There is a function call CFG_MM_MemFreeBytes
  2. This is a pointer that keeps moving at every step
  3. When ROM finishes Initialization, available RAM is pointing to this
  4. When PATCHES finish Initialization, available RAM is pointing to this
  5. When the App finishes the Initialization, available RAM points to this area
  6. We can find how much we need by making 2 calls to RAM:
  7. 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
  8. 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

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

2712 Views
Comments
MiTo_1583836
Level 5
Level 5
50 likes received 25 likes received 10 likes received

In case there is a requirement for a a bigger application (bigger than 26K) running on a 2073xS (SiP), something like 100K for example. It is still possible to connect an extra SF and boot from it directly?

asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

> It is still possible to connect an extra SF and boot from it directly?

No. This is not possible. However, you can use the overlay mechanism where you can split your app into orthogonal source files (up to 7 blocks of code where there are no cross-references between overlaid blocks of code) which will be loaded into a common area in the internal SRAM (size of which will be the largest overlay) on-demand. This is done only for code (RW and ZI will never be overlaid) and will work with EERPOM or Serial Flash (though loads from EEPROM will be slower than SF).

StBa_721356
Level 5
Level 5
50 likes received 25 likes received 10 likes received

Is there documentation available about the code overlay feature?

MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

Unfortunately, I don't think any formal documentation exists for this feature.  This thread could however be turned into a blog at some point if enough detail is provided.

j.t

asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

See SDK 1.1 RAM/proximity_plus sample application. This uses two overlaid sections of code. The application's makefile has some comments that describe how to overlay your code. SDK 2.x has a few minor issues in some of the build automation when the overlaid code is built. So you will have some build errors with SDK 2.x. This will be fixed in the next SDK so you will be able to use it exactly as in SDK 1.1

Anonymous
Not applicable

The Data only (stack ) area were 30 Kbytes, Can we reduce the to 20 Byte and increase the ram area for Application code.  Was 30 Kbytes the restricted BLE stack of WICDE?

Anonymous
Not applicable

I understood the 30 K bytes which can not be modified because ROM was used by ROM .

  • The ‘Data ONLY’ area in yellow is the data area allocated by the BLE stack that’s in the ROM
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

Unfortunately, we do not support the manipulation of the memory map in order to obtain additional space for the application:

1.

On the previous generation of devices, A0 Firmware, the free space for the application is ~17K

2.

On the current generation of devices, A1 Firmware, the free space for the application is ~27K

Anonymous
Not applicable

1. A0/A1 mean the FW version , some thing like SDK 1.1 and 2.x Right?

2. Do we have any recommend if we need the same algorithm may need more than 25 Kbytes?

MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

1.

Correct

2.

If the application is >27-30KB, paging from NV memory is possible but limited by the bus speed. An overlay is the mechanism used to in software to achieve the paging in and out of NV memory.

Take a look at this thread: Re: How to load the code dynamically ?

Anonymous
Not applicable

Aother Question:

1. which area used to store the GATT database.

2. Yellow Data 30 K bytes , which only used by ROM APP. only RW , ZI . not CODE and RO.

3. For quesiton 2, I would like to comfrim the ROM APP was XIP.

4. Why the application code can not be XIP?

Note:

XIP: Execute In Place

asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

1. All you app code, data (RW and ZI), RO goes into RAM (User Application Code/Data area). Your GATT DB goes in here.

2. This is RW and ZI used by the ROM FW (not the ROM apps).

3. ROM apps are execute in place, but the code and RO will be in ROM.

4. Application is executed in-place. If its a ROM app, from ROM and if its your app, its from RAM. If you meant why not execute from NV, then that is is because (1) the interface to NV is serial and (2) NV is not on the processor bus.

Anonymous
Not applicable

thank for clarify. Our Application was in the NV which can no not be execute in place.

Anonymous
Not applicable

On BCM27037S and SDK2.x, max sizes of available RAM for global, stack, heap variables are 30KB, 1KB, 26KB, right?

To be exact, code size + SIZE_H <= 26KB, SIZE_G <= 30KB, and SIZE_S <= 1KB are correct?

char g[SIZE_G];

void test(void){

  char s[SIZE_S];

  char *h = malloc(SIZE_H);

}

asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

I wouldn't put such numbers on it. There is about 30+KBytes of SRAM available for the application to use. The application thread stack (default is 1K) and some other buffers take up ~4K out of this (with default configurations). The remaining ~26K can be used by the application for more dynamically allocated buffers [creating new buffers using cfa_mm_Sbrk(), changing default allocations using blecm_SetApplicationThreadStackSizeInWords() or cfa_mm_ConfigureMemoryPool() ], allocating globals [RW/ZI], constants and code.

So size of all dynamic allocation (defaults or not) + sizeof(RW) + sizeof(ZI) + sizeof(RO) + sizeof(CODE) + sizeof(PATCHES) <= ~30K. How these are partitioned is not important.

Anonymous
Not applicable

Thanks

Anonymous
Not applicable

Is there an error with the size of SS2 (256b @ 0x100)?  If SS2 is really 256 bytes, then it should end at 0x200 which overlaps with VS1 which starts at 0x140?

MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

Please post this as a question in the Smart forums as I am not sure anyone other than myself (Community Manager across all spaces) monitors questions posted against blogs and documents.

Anonymous
Not applicable

Ok, I'll do that

Anonymous
Not applicable

Hello.

I have the BCM20737S on a custom board.

I am currently trying to figure out will I need external memory to store some data. Ideally I will get away with the ram on the module.

I have a sensor sending back data at 1.666khz, so I will have 1666 samples per second. If I sample for 2 seconds I will have 3332 samples. There is two of these sensors so there is the possibility of 6664 samples to be stored. Each sample is 16 bits.

6664 * 16 = 106624 bits. Turn this into bytes, 106624 / 8 = 13328 bytes. Turn this into Kb, 13328 / 1000 = 13.328 Kb.

Is there room on the ram to store 13kb worth of data? Looking at the original post there is 30k stack (data only).

Regards,

Luke..

MiTo_1583836
Level 5
Level 5
50 likes received 25 likes received 10 likes received

You have about 26KB worth of application space in RAM. If your application (not including sample storage) is below 13KB you have enough room. The 30K stack data only does not include dynamic data it is only static. The only value that you should look at is the 26K of application as approximation.

In our Mpression/Odyssey design we are mirroring data from external flash into a static array of 4096Bytes. It is actually eating up my application space, so now I really have 26K-4K worth of extra space to put my application code.

Contributors