How to Determine Actual Code Size and NVRAM Record Size?

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

cross mob
Anonymous
Not applicable

Hello,

  We have a need to maximize the amount of EEPROM we can use for storing recorded application data.  That being said I believe I am understanding how I can adjust the *.btp file and the ws_upgrade.c file for the correct ds, ss, and vs locations and length to maximize the vs size.  That being said I have 2 questions in regards to this.

1) In using the cfa_memfree() I can see that there is 16196byte left FREE in RAM.  So if I subtract this from 60KB(60*1024) which is the total available RAM internally on the BCM2073x I end up with 45244 bytes total that are apparently being used up.  If I subtract out the SS location which is from what I understand 256bytes that leaves 44988bytes which I would have to assume is what my actual code size is though this can't be the case?  Can you help me understand how to calculate the actual code size based on what is output from the cfa_mm_MemFreeBytes() API function?

2) Regarding NVRAM DLConfigVSLength and correspondence to ID's which range from 0x00-0x6F.  I am rather confused by what is being termed the 'Item' or 'Record' length.  I understand that the Page size is 32bytes and that each page has a 3byte overhead.  So my question is if I was to say use a 'Item/Record' length of 128 for each of the ID's 0x00-0x6F would I need to make the DLConfigVSLength = 112(6F + 0 location) * 128 = 14336?

3) It is imperative that I truly understand how to calculate the actual code size from the cfa_mm_MemFreeBytes() function output OR is there some means to inspect some sort of a file that actually shows the compiled sections so I can see from that what the actual individual section sizes are.  Being that it is a GNU/GCC compiler I would think there is a means to show the actual compiled listing or memory map file as can be done with a typical MCU.  I can't seem to find any sort of file output that shows this vs. having to backwards calculate from the leftover memory.

Regards,

Frank

0 Likes
1 Solution

Hi Frank,

1) The cfa_mm_free function returns memory to the heap and you input a pointer to the memory block that needs to be freed. now the SS location you subtract is for EEPROM and not RAM. So there is a confusion there. And cfa_mm_MemFreeBytes returns the number of bytes free in RAM.

2) There is an explanation here nvram: number of locations to write to

3) When you build your application in the console there is this log that appears displaying the size

Conversion complete

OTA image footprint in NV is 8501 bytes

thnx

vik86

View solution in original post

0 Likes
8 Replies
Anonymous
Not applicable

As a comment on item 1) I am sure that there is a portion of the RAM that is being used by the Stack itself.  So again how can I determine the amount of usage the Stack is using to subtract this from the amount of RAM being used to determine my actual code size?  Again it would be very convenient if I could simply look at a MAP file or something that actually shows the compiled code size that is being stored in the DS location.

Regards,

Frank

0 Likes

embeddedmasters

Can you confirm that you have already read through the following threads as I do not believe there is a simple/straight-forward answer (like using cfa_memfree) for the remapping of the VS Space in EEPROM.

nvram: number of locations to write to

WICED Smart BCM92073X EEPROM and SFLASH Layout

The last post here by maxsong tries to make some sense of the multitude of complexities that goes into this calcuation: What the biggest size of file system can be adjusted? (20737S)

I can try to track someone down internally that understands this, but I'm not sure the answer is going to be exactly what you are looking for...

leo_su roger_lu janusw michaelnelson zhaohua mudel vik86

0 Likes
Anonymous
Not applicable

Hello,

  I understand how to modify the VS sections the problem is that unless I know how big my actual code size is I have no idea how big I can make the VS section.  There has to some means to accurately know the compiled size of the program/firmware that needs to be stored in the DS section.

Regards,

Frank

0 Likes

Hi Frank,

1) The cfa_mm_free function returns memory to the heap and you input a pointer to the memory block that needs to be freed. now the SS location you subtract is for EEPROM and not RAM. So there is a confusion there. And cfa_mm_MemFreeBytes returns the number of bytes free in RAM.

2) There is an explanation here nvram: number of locations to write to

3) When you build your application in the console there is this log that appears displaying the size

Conversion complete

OTA image footprint in NV is 8501 bytes

thnx

vik86

0 Likes

vik86 Per an email embeddedmasters sent to me:

"Just to be clear I don’t have a question on the memory map itself I just need to know how to precisely determine how big my compiled code size is that is going to need to be programmed into the DS(program space) inside of the EEPROM.  Yes what is typically termed as a MAP file will show the compiled sections of a firmware project both RAM and Flash/Program space on a MCU.  I don’t know if this exists in the compiled output from the GNU compiler in the SDK or what method I should use to accurately know how big my compiled code space is to then know how big I can make the VS space which I want to make as big as possible for data storage."

0 Likes
Anonymous
Not applicable

It seems there is not such MAP file generated by IDE.

But we still can get such information via some .list/.lst files which are located in some different directories.

Because the final code includes both application and patches.

0 Likes
Anonymous
Not applicable

Agree.

The most simple way is to check the build log in the console:

OTA image footprint in NV is 7798 bytes

So, the code size(RO+RW) is 7798 bytes which will be programmed into the DS section.

We can also open the generated hex file(xxx-release.hex) and do some simple calculation. OR

check the generated bin file (xxx-release.ota.bin).

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

Regarding item 1.

NVRAM Storage has completely different characteristics as compared to Runtime/RAM, so trying to use a RAM based function like cfa_mm_MemFreeBytes() function will only confuse the mattter. For instance, RAM is not compressed, where as the contents in NVRAM are compressed.

0 Likes