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.
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.
The last post here by userc_4697 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...
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.
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
"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."
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).
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.
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.