Please take a look at hello_sensor.c in the SDK 2.2
Scan for Overlays in the code.
I am sorry, what Overlays ?
If the application is >27-30KB, paging from NV memory is possible but limited by the bus speed.
I believe the overlay is the mechanism used to in software to achieve the paging in and out of NV memory.
The developers told us today that they believe the Hello_Sensor application uses these overlays.
I'm not sure how well this is documented in the code.
I cannot find any overlay in hello_sensor.c - SDK 2.2. Any line number please ?
Have the issues with building overlaid code been fixed in SDK 2.x (if yes then in what version of SDK) ?
1 of 1 people found this helpful
Use SDK 2.1.1 and above for 20736/7 and SDK 1.1 for 20732.
In your application's makefile.mk, declare a new make variable called OVERLAY_SRC and set it to the list of source files that need to be overlaid.
OVERLAY_SRC = _0_overlaid_source_file0.c _1_overlaid_source_file1.c _2_overlaid_source_file2.c
APP_SRC = non_overlaid_source_file.c another_non_overlaid_source.c
You cannot overlay more than 7 source files and all overlaid sources should start with a '_NUMBER_' like in the example above. You must start with _0_ and cannot skip indices. Only code and RO sections will be overlaid (RW data in these will be allocated space in the non-overlaid region of RAM). Since all overlaid sources are linked at the same location in SRAM, you cannot have crossreferences between overlaid regions of code (you can always access non-overlaid code, ROM and patches).
Each overlaid file has an overhead of 4 bytes and each exported function in an overlaid source will have a 10 to 12 byte overhead (so declare static, functions that don't need to be available to the non-overlaid code).
Overlaid sections of code will be loaded automatically, just call functions in overlaid sections like you would regular functions. Since each section of code is loaded on-demand, there may be a long delay when invoking functions that are in a section that needs to be loaded into SRAM first. The load speed/latency depends on the NV - EEPROMs are an order of magnitude slower than SF. If you don't carefully split your code into orthogonal sections you might thrash a lot, so put related code together.
For the each overlaid regions , Is any size limitation ? the same 26Kbytes ?
Something of the order of 26K would be the absolute max size of any overlay (size of the RAM allocated for all the overlays is the size of the largest overlay). There must be some non-overlaid code - the application init, and create functions, patches and other included libraries, RW and zero-initialized data, so whatever remains can be used for overlays.
We co-work with the some health algorithm programmer, They can not want to release to C code to us and instead of the object code. Due the RAM limitation, we have to put their object into the overlaid region. If we only have the object how to do this. Please advise this. thanks
In your application directory, create a new directory and call it 'obj_secret' (without the quotes). Place the object files in this directory (make sure that the object files have been compiled with the same compiler options as the ones used by the SDK - set VERBOSE=1 to see the options the SDK uses). Make sure you adhere to the naming conventions required for enabling overlays (_NUMBER_filename.o). Edit your application's makefile.mk and add OVERLAY_SRC = _NUMBER_filename.c
Then clean and rebuild the app.