nRF51822 flash programming problem

RE: nRF51822 flash programming problem

Vidar Berg — Fri, 04 Dec 2015 13:42:20 GMT

updated my answer above

RE: nRF51822 flash programming problem

Max — Fri, 04 Dec 2015 08:22:10 GMT

I don't understand linker description in your answer. Please elaborate how it affects 16KB-RAM vs. 32KB-RAM BLE Nano.

Also, do you mean the examples in SDK 9 are for 32KB-RAM only? If so, how do I modify make file to work for xxAA chip.

RE: nRF51822 flash programming problem

Max — Thu, 03 Dec 2015 03:19:13 GMT

I found that the same gcc hex file works in 32KB-RAM Nano but fails in 16KB-RAM one. So I figure the hex compiled by gcc somehow requires more RAM usage. How do I check RAM size requirement?

RE: nRF51822 flash programming problem

Vidar Berg — Wed, 02 Dec 2015 14:22:49 GMT

Just so I understand correctly, the .hex built with GCC only fails run from time to time, or is it not working at all anymore? Also, is the "_build/app_button.o not found" error not consistent?

RE: nRF51822 flash programming problem

Max — Wed, 02 Dec 2015 14:13:30 GMT

I didn't modify the .ld file. Both 16K-RAM and 32K-RAM versions of BLE Nano have the same problem. What puzzles me is that Keil-compiled hex (the same c source codes) works although its hex file is smaller than gcc-compiled one (55KB vs 89KB).

RE: nRF51822 flash programming problem

Vidar Berg — Wed, 02 Dec 2015 11:47:14 GMT

Do you have any other makefiles in the same directory where you call Make? I think it's strange that the "_build/app_button.o not found" error is not consistent for every build.

Unrelated to the build error, but have you adjusted the linker settings in the .ld script? The examples are by default configured for the xxAC chip variant which as 32K of RAM as opposed to 16K on the RBL BLE Nano i think (chip overview). The gnu linker places the call stack in top of RAM rather than on top of the application region as with Keil.

UPDATE 4/12 - 2015

Attached the image below to better illustrate the difference between Keil projects and GCC projects in how the call stack is being linked. Also see the softdevice specification here for more details.

Point is that an application configured for 32K of RAM may still run on a 16K part when using Keil as the call stack may still be placed below the 16K limit (0x20004000 - depends on the size of the application RAM), and with GNU it will always be linked to the top of RAM regardless. Thus, outside of the available RAM. It's important to always have the correct linker settings part your are targeting in order to get a linker warning in case you are running out of memory.

You can edit the linker file to adjust the memory layout. For GCC you do it in the .ld script typically located in the same directory as the Makefile.

Example .ld file for 256K/32K RAM variants running s110 v.8.0.0:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x18000, LENGTH = 0x28000
  RAM (rwx) :  ORIGIN = 0x20002000, LENGTH = 0x6000
}

and same for 256K/16K:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x18000, LENGTH = 0x28000
  RAM (rwx) :  ORIGIN = 0x20002000, LENGTH = 0x2000
}