MCUxpresso link a function of a lib to RAM

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MCUxpresso link a function of a lib to RAM

938 Views
thieulam
Contributor III

Hi everyone. I need to make sure that a particular function (arm_sqrt_f32) present in the libcr_c.a library is mapped to RAM and not to FLASH. Is it possible to do this leaving the "Manage linker script" option enabled? Or is it necessary to use a custom script linker?

0 Kudos
7 Replies

898 Views
thieulam
Contributor III

The chip is:

mkv58f1m0vlq24

0 Kudos

914 Views
ZhangJennie
NXP TechSupport
NXP TechSupport

Hi @thieulam 

Please let us know your chip part number thus we can assign right engineer for it.

Thanks,

Jun Zhang

0 Kudos

511 Views
thieulam
Contributor III
Hello... any solution from support?
0 Kudos

873 Views
thieulam
Contributor III

mkv58f1m0vlq24

0 Kudos

821 Views
CarlosGarabito
NXP TechSupport
NXP TechSupport
0 Kudos

797 Views
thieulam
Contributor III

Thanks for the reply.

But actually I wanted to understand how to link a function present in an already existing library (.a), on the RAM and not on the flash..

I found the solution of how to link some functions I made on RAM, but I don't understand how to do it on already existing libraries (.a).

0 Kudos

791 Views
frank_m
Senior Contributor III

The basic idea is to copy the function in question from Flash to a certain RAM location (usually at startup time), and have all calls to this function linked to this RAM address. This requires support of both the linker, and respective startup code. As a side note, the IAR toolchain has direct support via the __ramfunc qualifier.

> I need to make sure that a particular function (arm_sqrt_f32) present in the libcr_c.a library is mapped to RAM and not to FLASH.

Though I would check if you really gain anything here.
It looks like you are going for performance. While RAM latencies are certainly shorter, this does not necessarily translate into higher performance. An instruction fetch is not bound to architecture size. Many vendors have 64-bit or 128-bit wide I-bus access for their Cortex M devices, which makes up for  their greater Flash latencies.

The most common rationale for RAM functions is IAP access in a single-bank Flash device, where you can't erase/program Flash and fetch instructions from it at the same time.