Which SDK11 gcc examples work with nRF51822?

[Roger Clark]

I think similar issues have been posted before and not resolved

If I flash the hex precompiled hex files for virtually any project by using the pca10028 S130 version it works fine

e.g. examples\ble_peripheral\ble_app_hrs\hex\ble_app_hrs_s130_pca10028.hex

But if I try to compile using gcc 4.9.3 the resultant binary doesn't work.

(I have the S130 SDK11 installed), I just flash the code into 0x1b000

The only example that does compile and run is

examples\ble_peripheral\ble_app_beacon\pca20006\s130\armgcc

i.e This targets the pca20006 board.

The pca20006 is a nRF51822 where as the pca10028 is a nRF51422 - so I don't know if that's the problem.

I'm now downloading keil to see if this is a gcc issue (I'm using gcc 4.9.3 as recommended here devzone.nordicsemi.com/.../ )

But the gcc toolchain must be working as the beacon for pca20006 will compile, upload and run without any problems

[Einar Thorsrud]

I suspect you have a device with 16 kB RAM (which is the case for the pca20006 board). Then you must modify your linker script appropriately. Taking the HRS example in SDK 11, this is <SDK>examples\ble_peripheral\ble_app_hrs\pca10028\s130\armgcc\ble_app_hrs_gcc_nrf51.ld. There you need to take the RAM LENGTH and subtract 0x4000, as the existing value is for a 32 kB RAM part.

That means that you should change line 9 from this:

  RAM (rwx) :  ORIGIN = 0x20001870, LENGTH = 0x6790

to this:

  RAM (rwx) :  ORIGIN = 0x20001870, LENGTH = 0x2790

The reason this (coincidently) works with Keil and not with GCC is differences in the memory allocations, which is entirely up to the compiler.

[Einar Thorsrud]

Regarding the different RAM usage by the SoftDevice for different examples, this is something that was introduced in S130 version 2. Depending on how the SoftDevice is configured, it will require different amounts of RAM. This is described in the S130 v2 release notes. If you enable logging and use a debugger, the SoftDevice will output the "correct" ram start address, as described in the release notes. If you use an example and does not modify it significantly (no more connections etc.), you should not have to change the start address.

In what way does it not work? As long as you set aside (at least) enough RAM for the SoftDevice, you should be OK. If there is not enough RAM left for the application, you should get an error during linking.

What is the rest of the marking on the 16 kB RAM chips you have? There are 3 generations of QFAA devices, and the latest SDK and SoftDevice are only compatible with the 3rd generation, marked "QFAAH..". See nRF51 Series IC revisions compatibility with SDK and SoftDevices for details.