nRF51822: Same code. Keil works but arm gcc doesn't

[Thumb2]

Hi,

We have a nRF51822 project based on ble_app_hids_keyboard, SDK 12.3. When using Keil, it runs well. However, when using arm-gcc to compile the same code, something wrong during execution.

With O3 optimization, I got this with gdb backtrace:

(gdb) c
Continuing.
nrf51.cpu -- clearing lockup after double fault

Program received signal SIGINT, Interrupt.
0xfffffffe in ?? ()
(gdb) backtrace
#0 0xfffffffe in ?? ()
#1 <signal handler called>
#2 0x00000776 in ?? ()
#3 <signal handler called>
#4 0x0002786a in sd_softdevice_enable (p_clock_lf_cfg=0x20007f78,
fault_handler=fault_handler@entry=0x27875 <softdevice_fault_handler>)
at ../../../../../../components/softdevice/s130/headers/nrf_sdm.h:228
#5 0x000279a8 in softdevice_handler_init (p_clock_lf_cfg=p_clock_lf_cfg@entry=0x20007f78,
p_ble_evt_buffer=p_ble_evt_buffer@entry=0x200023d4 <BLE_EVT_BUFFER.9343>,
ble_evt_buffer_size=ble_evt_buffer_size@entry=72, evt_schedule_func=<optimized out>)
at ../../../../../../components/softdevice/common/softdevice_handler/softdevice_handler.c:296
#6 0x0001e1e0 in ble_stack_init () at ../../../main.c:1270
#7 main () at ../../../main.c:1446

With O2 or Os optimization, it resets repeatedly and I don't know what causes this.

The arm-gcc version:

arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]

Any hints? Thanks in advance. 

[Nguyen Hoan Hoang]

It looks like you haven't flash softdevice.  Softdevice need to be flashed in first once.  After that you flash your firmware.  See this blog for nRF51 & nRF52 development with Eclipse GCC  

[Thumb2]

I have flashed softdevice, otherwise the firmware built by Keil won't work.  

I tried the original hid keyboard example with arm-gcc and it works, so the problem should be related to our modification. However, I have no idea why Keil works while arm-gcc doesn't for our codes (only C implementation, and I'm trying to find out the reason).  

[Nguyen Hoan Hoang]

Check for memory alignement.  The M0 cannot handle unaligned access.  I think since gcc ver 5. with optimization enabled it packs everything byte aligned. 

for example you have 2 global var declared in this order :

uint8_t a;

uint32_t b;

accessing b could caused a crash.  This is only affect global and structures.  Local var are on the stack which is aligned 4 already.