nRF51822 GCC Eclipse HardFault in SystemInit

[matterama]

Hello all,

I have migrated a project that was working well (on custom hardware) in Keil to gcc/Eclipse. I followed all the instructions on this site:

https://devzone.nordicsemi.com/tutorials/7/development-with-gcc-and-eclipse/

and except for a few little hiccups, it went smoothly. The project compiles and I can load the code using the DK51 board to the target board, just like the Keil setup.

However, I'm encountering a hard fault before hitting main.

Single stepping thru, I see the following:

1. Enters the Reset_Handler in gcc_startup_nrf51.s (though I've moved a copy of this locally to keep the project files all in one place).

2. Proceeds ok up to "LDR R0, =SystemInit"

3. On the next instruction, BLX R0, the code jumps correctly into SystemInit

4. Using single step instruction mode, I proceed as it calls "is_manual_peripheral_setup_needed()" in system_nrf51.c. 5)

5. At the end of this function, it is returning false (which is correct). However, it never returns. Instead, it does this (disassembly): -- movs r3, #0 (this is correct, it is moving a "false" into the register for returning -- adds r0, r3, #0 (ok) -- mov sp, r7 (ok) -- pop {r7, pc}

on the pop command, the software jumps to memory 0x00 where the __Vectors: are located. It goes thru a few instructions here until hitting the ldmia r0, {r0, r1, r5} command, then hard faults.

I'm a bit at a loss. Any ideas on where to look or what might be going on here?

Thanks!

[RK]

Where's your stack pointer? Sounds like you're failing on the first return from a BX which makes me wonder where it's getting the address from. I assume at the start of the function it pushes r7 and lr to the stack, should be able to see where it's pushed them and what they are.

[Nguyen Hoan Hoang]

Check your linker script. The RAM setting may be wrong. I suspect the 32KB settings in the LD while your chip may have only 16KB.

[matterama]

THANK YOU! I had the 32kB RAM in there....the date code on the chip had AC, which was mistakenly read as the chip type, not AA like it is!

[matterama]

Thank you for your suggestion. See below, it was a dumb mistake...

[RK]

Right - because the GCC linker script puts the stack at the end of user memory - so if you tell it you have more memory than you do, it ends up in no-mans land. If you'd checked the stack pointer when running you'd have seen the area it pointed to was all 0xFF and you BX commands weren't writing anythign there.