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.

[Roger Clark]

I just checked the 2 boards I was trying and you are right. They were fitted with AA not AC devices.

I have 6 development boards from WaveShare and the first 2 both had AC devices, so I assumed all the other boards were also AC versions.

But it looks like somewhere in the supply chain, someone decided to use AA versions to reduce costs.

I will try the boards with AC devices and then change the linker file and retest on the AA devices.

BTW. perhaps GCC puts the stack near the end of RAM

Anyway, I will double check and mark the question as Answered if that fixes the problem

[Einar Thorsrud]

You are right, GCC places the stack in the end of the RAM.

[Roger Clark]

OK.

I tried the nRF51822 QFAC board, and it does work with the existing pca10028

But changing the RAM settings in the linker file didnt make it work for the AF AA (16k device)

Looking at the RAM settings for ble_peripheral\ble_app_hrs\pca10028 (SDK11)

  RAM (rwx) :  ORIGIN = 0x20002080, LENGTH = 0x5f80

Both the RAM origin and also the LENGTH are different from the ble beacon example

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

So I tried using the RAM settings for the pca10028 but deducted 16k from the LENGTH

  RAM (rwx) :  ORIGIN = 0x20002080, LENGTH = 0x1f80

It looks like the SD has been allocated more RAM in pca10026 than the SD for the Beacon, but they are both using S130 SD, so I'm not sure why this is different.

However this didn't work either :-(

Perhaps the hrs will not run in 16k RAM.

[Roger Clark]

BTW. I looked at the IAR project files and the settings appear to be the same values as gcc

define symbol __ICFEDIT_region_RAM_start__   = 0x20002080;
define symbol __ICFEDIT_region_RAM_end__     = 0x20007fff;

Note. This start address is still different from the start address in the Beacon example

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