Linker on Nordic nRF51822 `cannot move location counter backwards`.

[nuket]

I'm trying to build a simple project but ld keeps complaining, when tried with both gcc 4.9 and gcc 5.4:

gcc 4.9 says:

./mbed-os/hal/targets/cmsis/TARGET_NORDIC/TARGET_NRF5/TARGET_MCU_NRF51822_UNIFIED/TOOLCHAIN_GCC_ARM/TARGET_MCU_NORDIC_32K/NRF51822.ld:142 cannot move location counter backwards (from 0000000020007fd8 to 0000000020007800) collect2: error: ld returned 1 exit status [ERROR] ./mbed-os/hal/targets/cmsis/TARGET_NORDIC/TARGET_NRF5/TARGET_MCU_NRF51822_UNIFIED/TOOLCHAIN_GCC_ARM/TARGET_MCU_NORDIC_32K/NRF51822.ld:142 cannot move location counter backwards (from 0000000020007fd8 to 0000000020007800) collect2: error: ld returned 1 exit status

All of the code compiles fine, it's only the link step that is erroring out. Is it possible that I'm out of memory?

The mbed-os version number, using the mbed CLI:

mbed-os (8d368775e32a)

I tested the mbed OS Blinky example, and it builds fine.

[bridadan]

I'm pretty sure when I've seen this error it's because I was out of memory.

@pan- Do you think that's the case?

[nuket]

Looks like this could be the case, but if those values returned by the linker are correct, I'm not looking forward to optimizing down 2k worth of code. Things are pretty tight on the chip already and I'm not even close to done with my firmware.

Also asked this question at the Nordic support forum, and they referred to another link with a similar conclusion.

• https://devzone.nordicsemi.com/question/91007/linker-cannot-move-counter-backwards-on-mbed/?answer=91073#post-id-91073
• https://github.com/RIOT-OS/RIOT/wiki/Troubleshooting#question-2

[nuket]

Ok, I figured out where a ton of test code from a library was being pulled in by the mbed compile command. Added an .mbedignore to that folder and the problem went away.

Ticket can be closed.

[pan-]

@nuket @bridadan Yes, there is not enough RAM for the application.

The inclusion of the OS add a non negligible overhead. RAM optimization is a trending topic for mbed OS right now and several patches will help.

You can apply workarounds now:

• disable utest overhead: If you don't use utest and/or unity in your application you can disable them totally, this will FLASH and RAM in your application. To do that, at the root of your application create a file named .mbedignore and add this content in it: mbed-os/features/frameworks/*. It will save you around ~1K of RAM. Efforts are made to solve this issue cleanly (see here).
• Compile with NDEBUG. mbed cli does not pass NDEBUG flag for release builds, this can help regarding memory consumption (pass -DNDEBUG) in the command line.
• If you don't use RTOS capabilities, it is possible to use nanolib instead of newlib. To do that, apply this PR: https://github.com/ARMmbed/mbed-os/pull/2409 and pass the option -o small-build on the command line.

[nuket]

Thanks for the suggestions, I'll try them out incrementally!

[pan-]

@nuket These optimizations will be gradually included in mbed-os, I think the situation will be better in few weeks.

[bridadan]

@pan- You're right, we're on it :)