Announcements
IMPORTANT: Cypress Developer Community is transitioning on October 20th. To learn more and be prepared for this change, check out our latest announcement.
cancel
Showing results for 
Search instead for 
Did you mean: 

WICED 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.