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?

Parents
  • Can we get a register dump after you get to hardfault? Knowing where the SP is would be helpful for one. That stack trace looks as if the first call (ie first branch link) has stacked the return address, done the work and then returned to nowhere and faulted. The most likely cause of that is a stack pointer not initialised correctly on startup without the debugger.

Reply
  • Can we get a register dump after you get to hardfault? Knowing where the SP is would be helpful for one. That stack trace looks as if the first call (ie first branch link) has stacked the return address, done the work and then returned to nowhere and faulted. The most likely cause of that is a stack pointer not initialised correctly on startup without the debugger.

Children
No Data
Related