This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
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:

RBL BLE Nano

nRF51_SDK_9.0.0_2e23562

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

Parents
  • 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:

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

Reply Children
No Data
Related