How to load the code dynamically ?

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

cross mob
Anonymous
Not applicable

How do I (or is it possible) to load the code from FLASH into RAM dynamically to extend the 27K limit for the user app ?

0 Likes
1 Solution

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.

View solution in original post

11 Replies
Anonymous
Not applicable

Hello Lukasz,

Please take a look at hello_sensor.c in the SDK 2.2

Scan for Overlays in the code.

Thanks.

JT

0 Likes
Anonymous
Not applicable

I am sorry, what Overlays ?

0 Likes

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.

0 Likes
Anonymous
Not applicable

I cannot find any overlay in hello_sensor.c - SDK 2.2. Any line number please ?

0 Likes
Anonymous
Not applicable

Hello Lukasz,

Sorry, wrong file.

Please look at this post: BCM20732 Memory Map Architecture

There is a discussion here as well:

BCM20732 Memory Map Architecture

Hopefully this helps

Thanks

JT

0 Likes
Anonymous
Not applicable

Have the issues with building overlaid code been fixed in SDK 2.x (if yes then in what version of SDK) ?

0 Likes

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.

Anonymous
Not applicable

For the each overlaid regions , Is any size limitation ? the same  26Kbytes ?

0 Likes

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.

0 Likes
Anonymous
Not applicable

Question:

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

0 Likes

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.

0 Likes