This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Hardfault without debugger - simple toggle IO program

Hi guys,

I'm trying to start with a simple IO toggle program on the nRF52 on a Thingy52 board. I have erased the micro so there is no soft device. I'm working in Eclipse Neon 3 using ARM Cross Compiler plugin.

#include "nrf.h"    
#include "nrf_delay.h"
#include "nrf_gpio.h"

int main(void)
{
	nrf_gpio_cfg_output(2);

	for(;;)
	{
		nrf_gpio_pin_toggle(2);
		nrf_delay_ms(50);
	}

	return 0;
}

I can compile and run it OK with my Segger JLink connected. However when I turn it off/on without the debugger running the micro hangs and does not toggle. Reconnecting the debugger shows it's in HardFault_Handler and it got there via the sequence: image description

Others have suggested to disable semi-hosting which I believe I have done.

My compilation flags (excluding #include search folders) looks like:

arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mlittle-endian -mfloat-abi=hard -mfpu=fpv4-sp-d16 -munaligned-access -O0 -fmessage-length=0 -ffunction-sections -fdata-sections -fno-builtin -Wall -Wextra  -g -DNRF52832_XXAA -DNRF52_PAN_12 -DNRF52_PAN_15 -DNRF52_PAN_20 -DNRF52_PAN_31 -DNRF52_PAN_36 -DNRF52_PAN_51 -DNRF52_PAN_54 -DNRF52_PAN_55 -DNRF52_PAN_58 -DNRF52_PAN_64 -DNRF52_PAN_74 -std=gnu11 -Wa,-adhlns="src/src_nrf/nrf_drv_uart.o.lst" -fno-strict-aliasing -fshort-enums  -MMD -MP -MF"src/main.d" -MT"src/main.o" -c -o "src/main.o" "../src/main.c"

My linker script (mostly a copy of the generic one):

/* Linker script to configure memory regions. */

SEARCH_DIR(.)
GROUP(-lgcc -lc -lnosys)

MEMORY
{
   FLASH (rx) : ORIGIN = 0x0, LENGTH = 512K

   RAM (rwx)  : ORIGIN = 0x20000000, LENGTH = 64K
}

SECTIONS
{
  .fs_data :
  {
    PROVIDE(__start_fs_data = .);
    KEEP(*(.fs_data))
    PROVIDE(__stop_fs_data = .);
  } > RAM
} INSERT AFTER .data;

SECTIONS
{
  .pwr_mgmt_data :
  {
    PROVIDE(__start_pwr_mgmt_data = .);
    KEEP(*(SORT(.pwr_mgmt_data*)))
    PROVIDE(__stop_pwr_mgmt_data = .);
  } > FLASH
} INSERT AFTER .text

OUTPUT_FORMAT ("elf32-littlearm", "elf32-bigarm", "elf32-littlearm")

/* Linker script to place sections and symbol values. Should be used together
 * with other linker script that defines memory regions FLASH and RAM.
 * It references following symbols, which must be defined in code:
 *   Reset_Handler : Entry of reset handler
 *
 * It defines following symbols, which code can use without definition:
 *   __exidx_start
 *   __exidx_end
 *   __etext
 *   __data_start__
 *   __preinit_array_start
 *   __preinit_array_end
 *   __init_array_start
 *   __init_array_end
 *   __fini_array_start
 *   __fini_array_end
 *   __data_end__
 *   __bss_start__
 *   __bss_end__
 *   __end__
 *   end
 *   __HeapBase
 *   __HeapLimit
 *   __StackLimit
 *   __StackTop
 *   __stack
 */
ENTRY(Reset_Handler)

SECTIONS
{
    .text :
    {
        KEEP(*(.isr_vector))
        *(.text*)

        KEEP(*(.init))
        KEEP(*(.fini))

        /* .ctors */
        *crtbegin.o(.ctors)
        *crtbegin?.o(.ctors)
        *(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)
        *(SORT(.ctors.*))
        *(.ctors)

        /* .dtors */
        *crtbegin.o(.dtors)
        *crtbegin?.o(.dtors)
        *(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)
        *(SORT(.dtors.*))
        *(.dtors)

        *(.rodata*)

        KEEP(*(.eh_frame*))
    } > FLASH

    .ARM.extab :
    {
        *(.ARM.extab* .gnu.linkonce.armextab.*)
    } > FLASH

    __exidx_start = .;
    .ARM.exidx :
    {
        *(.ARM.exidx* .gnu.linkonce.armexidx.*)
    } > FLASH
    __exidx_end = .;

    __etext = .;

    .data : AT (__etext)
    {
        __data_start__ = .;
        *(vtable)
        *(.data*)

        . = ALIGN(4);
        /* preinit data */
        PROVIDE_HIDDEN (__preinit_array_start = .);
        KEEP(*(.preinit_array))
        PROVIDE_HIDDEN (__preinit_array_end = .);

        . = ALIGN(4);
        /* init data */
        PROVIDE_HIDDEN (__init_array_start = .);
        KEEP(*(SORT(.init_array.*)))
        KEEP(*(.init_array))
        PROVIDE_HIDDEN (__init_array_end = .);


        . = ALIGN(4);
        /* finit data */
        PROVIDE_HIDDEN (__fini_array_start = .);
        KEEP(*(SORT(.fini_array.*)))
        KEEP(*(.fini_array))
        PROVIDE_HIDDEN (__fini_array_end = .);

        KEEP(*(.jcr*))
        . = ALIGN(4);
        /* All data end */
        __data_end__ = .;

    } > RAM

    .bss :
    {
        . = ALIGN(4);
        __bss_start__ = .;
        *(.bss*)
        *(COMMON)
        . = ALIGN(4);
        __bss_end__ = .;
    } > RAM

    .heap (COPY):
    {
        __HeapBase = .;
        __end__ = .;
        PROVIDE(end = .);
        KEEP(*(.heap*))
        __HeapLimit = .;
    } > RAM

    /* .stack_dummy section doesn't contains any symbols. It is only
     * used for linker to calculate size of stack sections, and assign
     * values to stack symbols later */
    .stack_dummy (COPY):
    {
        KEEP(*(.stack*))
    } > RAM

    /* Set stack top to end of RAM, and stack limit move down by
     * size of stack_dummy section */
    __StackTop = ORIGIN(RAM) + LENGTH(RAM);
    __StackLimit = __StackTop - SIZEOF(.stack_dummy);
    PROVIDE(__stack = __StackTop);

    /* Check if data + heap + stack exceeds RAM limit */
    ASSERT(__StackLimit >= __HeapLimit, "region RAM overflowed with stack")
}

My linker call looks like:

arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mlittle-endian -mfloat-abi=hard -mfpu=fpv4-sp-d16 -munaligned-access -O0 -fmessage-length=0 -ffunction-sections -fdata-sections -fno-builtin -Wall -Wextra  -g -T "D:\nRF_Workspace_Neon3\Blinky2point0/linker/blinky_gcc_nrf52.ld" -Xlinker --gc-sections -Wl,-Map,"Blinky2point0.map" -Wl,--start-group -lgcc -lc -lc -lm -Wl,--end-group -o "Blinky2point0.elf"  ./src/src_nrf/gcc_startup_nrf52.o ./src/src_nrf/nrf_assert.o ./src/src_nrf/nrf_drv_common.o ./src/src_nrf/system_nrf52.o  ./src/main.o

Stack region of memory: image description

Can anyone please point me in the right direction?

  • The code around here is c library code:

              __register_exitproc:
    00000530:   stmdb   sp!, {r3, r4, r5, r6, r7, r8, r9, lr}
    00000534:   ldr     r5, [pc, #176]  ; (0x5e8 <__register_exitproc+184>)
    00000536:   mov     r6, r0
    00000538:   ldr     r0, [r5, #0]
    0000053a:   mov     r8, r3
    0000053c:   mov     r7, r1
    0000053e:   mov     r9, r2
    00000540:   bl      0x528 <__retarget_lock_acquire_recursive>
    00000544:   ldr     r3, [pc, #164]  ; (0x5ec <__register_exitproc+188>)
    00000546:   ldr     r4, [r3, #0]
    00000548:   ldr.w   r3, [r4, #328]  ; 0x148
    0000054c:   cmp     r3, #0
    0000054e:   beq.n   0x5ce <__register_exitproc+158>
    00000550:   ldr     r2, [r3, #4]
    00000552:   cmp     r2, #31
    00000554:   bgt.n   0x590 <__register_exitproc+96>
    00000556:   add.w   lr, r2, #1
    0000055a:   cbz     r6, 0x57a <__register_exitproc+74>
    0000055c:   add.w   r1, r3, r2, lsl #2
    00000560:   movs    r4, #1
    00000562:   str.w   r9, [r1, #136]  ; 0x88
    00000566:   ldr.w   r0, [r3, #392]  ; 0x188
    0000056a:   lsls    r4, r2
    0000056c:   orrs    r0, r4
    0000056e:   cmp     r6, #2
    00000570:   str.w   r0, [r3, #392]  ; 0x188
    00000574:   str.w   r8, [r1, #264]  ; 0x108
    00000578:   beq.n   0x5c2 <__register_exitproc+146>
    

    The application ends at 0x0D32, above that is blank flash.

  • ok there's more to it then. Firstly I was wrong, hardfault is a precise fault so 0x0550 is the instruction which was executing (not the return-to address). So you were doing ldr r2, [r3,#4]. No shock that faulted, r3 is 0xbb7dfffb which is rubbish.

    So r3 was loaded with (I think) 0x5ec. , r4 was loaded from that address, r3 was loaded from r4 + 328 and that was probably 0xbb7dfffb and that's not zero so the branch wasn't taken and then you HF at 0x0550 trying to load from that address + 4.

    At this point, that's all I can tell.

  • Yeah, thanks for taking a look! I might have to compare my compiler stuff with different example code. It's gotta be something... FYI 0x02AE is inside _start as a call to __libc_init_array

    I've also tried changing to newlib-nano and have exactly the same symptoms and still crashes inside __libc_init_array.

  • well go stick a breakpoint there and see what happens when you DO run under the debugger, perhaps that will hint what's going on. If it were a different debugger (like Segger Embedded or something) I'd suggest that perhaps it wasn't going from the reset handler and was doing something odd, but I'm reasonably sure gdb via gdbserver is pretty plain vanilla.

  • Using the debugger when it gets to

    00000550:   ldr     r2, [r3, #4]
    

    r0 = 536872028 = 0x2000 045C, r3 = 536871244 = 0x2000 014C

    These are valid areas in RAM. Without the debugger r0 and r3 become invalid.

Related