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
  • 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.

Reply
  • 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.

Children
No Data
Related