cancel
Showing results for 
Search instead for 
Did you mean: 

Smart Bluetooth

Anonymous
Not applicable

We have some A1 chips coming in.

We understand that we must use SDK 2.2 for A1 chip.

How much more code space / data space will new A1 chip provide?

0 Likes
1 Solution
MichaelF_56
Moderator
Moderator

We were able to manage patches more effectively in the A1 firmware (SDK 2.0/TAG3/20736/37), so the free RAM on A1 is close to 30K.

On A0 (SDK 1.x/TAG2/20732), I believe we were closer to 20K of free RAM.

View solution in original post

0 Likes
5 Replies
MichaelF_56
Moderator
Moderator

We were able to manage patches more effectively in the A1 firmware (SDK 2.0/TAG3/20736/37), so the free RAM on A1 is close to 30K.

On A0 (SDK 1.x/TAG2/20732), I believe we were closer to 20K of free RAM.

View solution in original post

0 Likes
Anonymous
Not applicable

Is that 30K exclusively for our application?  Or is it also shared with patches, or other API code or data?

0 Likes
Anonymous
Not applicable

Hello dbell,

The 30K is shared with patches so the available space for the App is ~28K.


JT

SuLe_1710756
Contributor

Hello j.t

I am confused about available space for the App.

As you said in the figure(Memory size limits on 20732?), user application(patch + application) can be used up to 26K.

However, you commented like this,

"

  1. The 30K is shared memory (between patches and the app) and the dynamically allocated buffers also take up some of this space.

I am sure that 30K for user application is correct because memory address(0x0000 ~ 0xFFFF) is 64K, where

4K is used for CM3, and 30K is for ROM, and the rest 30K is for user application. Am I right?

If then, your figure should be fixed like attached image, right?

BCM20732 RAM Memory Map.bmp

Thanks,

SM

0 Likes
ArvindS_76
Employee

The total ram is 60Kbytes, and not 64K as in the picture. If there is no application and no patches, then there is ~30Kbytes of free RAM. The actual amount of RAM used by the app depends on the app + patch code and statically allocated RAM + any dynamically allocated RAM for callback registrations, data buffers and memory pools. So adding a line of code can change this number quite dramatically (is it just a few instructions? Did it allocate RAM dynamically? Did it force the linker to pull in optional patches [some patches are linked in on-demand - if there is no reference to its API, it won't be linked in]?).

Instead of depending on a hard 'free RAM available for application', I suggest you determine this at run-time. At the end of your application create function, use cfa_mm_MemFreeBytes() to determine the number of free bytes till the end of RAM. Your application can grow (code + statically allocated memory + dynamic memory + patches) can grow by at most so many more bytes.