Problem with GNU compiler(2013q4) with SDK 6.1

RE: Problem with GNU compiler(2013q4) with SDK 6.1

RK — Tue, 07 Apr 2015 09:31:58 GMT

I didn't say change long_calls to mlong_calls I said compile that .c file with the -mlong_calls (or possibly -mlong-calls) compile option which should make it use long calls for all calls OUT of that piece of c code. I believe the pragma just makes it use long calls for calls INTO that piece of c, which you had already with your attribute, which also put it in the data segment. So put that back, take the pragma out and add the compilation flag to that one .c module so that when it compiles you get something like

gcc -o out.o -mlong_calls out.c

That's where you need it to be. If you check the assembler instead of BLX calls you should get an LDR to load the register and then a BL Rx.

By the way you're not necessarily helping yourself very much as the division library you are calling will still end up in Flash, so you'll be back to Flash to execute that anyway.

RE: Problem with GNU compiler(2013q4) with SDK 6.1

Anand Ramashetty — Sat, 04 Apr 2015 11:22:50 GMT

hi rk,

I have used #pragma long_calls instead of attribute((used, long_call, section(".data"))) and it successfully built. But the function is not moved to RAM.

Will it cause any issue?

Regards, Anand

RE: Problem with GNU compiler(2013q4) with SDK 6.1

Anand Ramashetty — Sat, 04 Apr 2015 09:04:59 GMT

Hi RK,

After changing the long_calls to mlong_calls , the same error I am facing. Can you please tell me what could be the cause.

Regards, Anand

RE: Problem with GNU compiler(2013q4) with SDK 6.1

Anand Ramashetty — Sat, 04 Apr 2015 08:53:52 GMT

Hi RK,

Thanks a lot for your clarification. Nordic suggesting that if we execute code from RAM instead of flash will help in power consumption. So I am trying to execute code from RAM instead of Flash.

Regards, Anand

RE: Problem with GNU compiler(2013q4) with SDK 6.1

RK — Thu, 02 Apr 2015 23:25:54 GMT

When you post code can you please use the post-code button so it looks like code instead of a jumbled mess of text, it's hard to read.

You used long_call in your function_1 definition to ensure anyone calling it uses a full 32-bit call, because you're putting it in the data segment. However you are then trying to call back to a normal system routine to do divide, which is in your code/text segment and is too far away for a normal

bl <immediate>

instruction on ARM, so it fails at link time.

If you compile the one .c file containing your RAM-based function with the -mlong_calls option that will make the udiv calls full 32-bit.

Why are you doing this anyway by the way? What's the need to run the code out of RAM?

RE: Problem with GNU compiler(2013q4) with SDK 6.1

Anand Ramashetty — Thu, 02 Apr 2015 14:35:40 GMT

I am using nRF51822 version 3.1 controller with SD110