nRF bootloader runs into HardFault

[liszi]

I'd like to run a softdevice application with OTA support on a RIGADO BMD-200 Evaluation board. I've successfully flashed the softdevice, the app, and the rigado bootloader, with rigado's program.py from the rigado bootloader-tools.

Now I want to switch to the open source nrf bootloader, so I've taken the example from nrf SDK (nRF51_SDK_9.0.0/examples/dfu/bootloader), and succesfully compiled it in eclipse, with rigado's costum_board.h. Then I start to use a linux implementation of nrfjprog to erease, flash softdevice and flash the bootloader example. This program is recommeded in the example. During debugging in eclipse I saw, that the program always stucks in the hardfault handler. I've already checked the bootloader starting address in the UICR, it's OK (10001014 = 0003C000).

After that I tried to flash the nrf bootloader with jlink, but the result HardFault again. Then I left out the debugger from the test, so I wrote 3 led switcher functions (red, blue, green), and call them in the startup.s file. For example red led switcher in the HardFault handler in the gcc_startup_nrf51.S file looks like this :

...    
HardFault_Handler:
        LDR     R0, =ledRed
        BX      R0
        B      .
...

The led enabling c function in main.c:

void ledRed(void){
    	LEDS_CONFIGURE(LEDS_MASK);
    	LEDS_ON(1 << LED_RED);
}

These led switcher functions only work when Os optimisation is set. (Why?)

With this kind of led debug I find out that that the program runs till

LDR     R0, =SystemInit
BLX     R0

lines in the gcc_startup_nrf51.S. When the program counter reaches this call, it causes a HardFault.

When I use -O0 optimisation I get the following message from the c compiler:

In function 'bootloader_util_reset':
../src_nordic/bootloader_util.c:106:1: error: r7 cannot be used in asm here

With -fomit-frame-pointer switch I can compile, but I don't know the proper meaning of the switch. However the led-s do not lights up with -O0, -O1, -O2, or -O3 optimisation setup, only with -Os. An other interesting thing: when I call the led functions in the asm code with BX insead of BLX I always get a HardFault after the led switch on.

I'm using the next setups in the project:

Project defines (for c com and assembler): SWI_DISABLE0 BOARD_PCA10028 SOFTDEVICE_PRESENT NRF51 S110 __HEAP_SIZE=0 BLE_STACK_SUPPORT_REQD.
Assembler options:-x assembler-with-cpp (and upper defines and include paths). C compiler options: -std=gnu99 -Wall -Werror (and upper defines and include paths).
Linker options: --specs=nano.specs -lc -lnosys -Xlinker --gc-sections (and linker script include path from the example)What does nosys option do?
Target options: cortex-m0, armv6-m.
Thumb Debug level: none (I'm debugging with leds now.)

I'm using Eclipse Kepler SR2, nRF51_SDK_9.0.0, with softdevice 8.0.0, SEGGER J-Link Commander V5.02c, arm-none-eabi-gcc v4.8.3, on kubuntu 14.04.

So after this long description, my main question is: why the program can't get in the main function? Have anyone seen similar problem before? Thank you for the help in advance.

[arthare]

I was having identical symptoms to liszi, but a different fix.

My setup:

• PCA10036 devkit with a 2015.40 stamp on it.
• Used ARM GCC toolchain to compile the blinky app from the 12.0 SDK (it was originally for PCA10040, but I changed all references to PCA10036)
• When I used keil to flash the devkit with the exact same blinky code, it worked. When I used make flash to do it, the thing would never boot
• So I debugged with jlink, stepping one instruction at a time, and found that the bl SystemInit in gcc_startup_nrf52.s seemed to cause it to go to hardfault.

My fix:

• Stop using my ancient devkit. I have a bunch of BMD-300s, so I programmed one of those and the exact same .hex that had been hardfaulting on the devkit worked.

Implied root causes:

1. Devkit was ancient
2. .hex was being compiled for the wrong CPU revision (seems unlikely to me, because Keil was still able to make a working .hex)