This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

nRF51822 flash programming problem

My setups are:



Keil uVision V4.74.0.22 or gcc-arm-none-eabi-4_8-2014q2-20140609-win32

My design is to advertise a manufacturer specific data containing a reading from one of the analog channels. The hex file compiled in uVision can be programmed successfully but the hex file by gcc fails from time to time. Both hex are merged with ~softdevice/s130/hex/s130_softdevice.hex before dragging it to MBED drive.

Strange thing is that the hex by gcc did work at some point of time but fail now. I notice that some gcc compilings show an error message saying "_build/app_button.o not found" but it's gone when I "make -f" again. The Makefile is attached for your reference. Please help.Makefile

  • 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.

    image description

    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:

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

    and same for 256K/16K:

      FLASH (rx) : ORIGIN = 0x18000, LENGTH = 0x28000
      RAM (rwx) :  ORIGIN = 0x20002000, LENGTH = 0x2000
  • 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).

  • 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?

  • 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?

  • 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.