Reset_Handler loops forever

Marlon,

Thanks for trying this toolchain. I think I need more information to analyze the issue.

Which Freescale board are you using? If it is MK60Nxxxx I might already know the reason.

- Joey

Hi,
We have the tool worked for Freescale's MK60N512 target board. One thing might be important is the link script.
If you are using the same board, please give below script a try. Or could you provide your target board/sample project/debug tools information for further investigation? Thanks.

/* Library configurations */
GROUP(libgcc.a libc.a libm.a libnosys.a)

/* Linker script to configure memory regions. */
MEMORY
{
  FLASH (rx) : ORIGIN = 0x0, LENGTH = 0x80000 /* 512k */
  RAM (rwx) : ORIGIN = 0x1FFF0000, LENGTH = 0x20000 /* 128k */
}

/* 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
 * __HeapLimit
 * __StackLimit
 * __StackTop
 * __stack
 */
ENTRY(Reset_Handler)

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

  /* hard code Flash configuration field of mk60n512 board. */
  . = 0x400;
  FILL(0xFFFFFFFF)
  . = 0x40c;
  LONG(0xFFFFFFFE)
  . = 0x410;
  FILL(0x00)
  . = 0x800;

  *(.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 = .);

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

 } > RAM

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

 .heap :
 {
  __end__ = .;
  end = __end__;
  *(.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 :
 {
  *(.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")
}

Thanks for the replies guys.

The board I'm using is the TWR-K20D50M. The linker script and startup code I'm using was copied directly from the readme; the only thing I did was change the memory section to this:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x0, LENGTH = 0x20000 /* 128k */
  RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x4000 /* 16k */
}

I noticed that the linker script and startup code in the readme is for an Cortex-M0, so I found one on the ARM website for an M4 and tried that as well without any luck.

Chengbin, I'll try the linker script you provided and let you know how it goes.

Ok, I tried that linker script but I'm getting the same result. Maybe there's something I'm missing; I'm new to working with startup and linker scripts.

Also, the debug tools I'm using are OpenOCD with arm-eabi-gdb. The freescale board has a USB debug interface on it that works with OpenOCD.

And here's the makefile I'm using:

CC = /home/marlon/downloads/gcc-arm-none-eabi-4_6-2012q2/bin/arm-none-eabi-gcc
LD = /home/marlon/downloads/gcc-arm-none-eabi-4_6-2012q2/bin/arm-none-eabi-ld

CPU_FLAGS = -mcpu=cortex-m3 -mthumb -fno-common -D__NO_SYSTEM_INIT -O0 -g -Wl,-T,PK20X128.x -Wl,--start-group -lgcc -lc -lm -lnosys -Wl,--end-group -Wl,-Map,aircon.map

all:
 $(CC) ${CPU_FLAGS} main.cc startup.S -o output.elf

Joey, is this issue you were thinking about this one? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka12545.html

I seem to be getting a hard fault a few instructions into the Reset_Handler, regardless of what the instructions are. If so, I'm not sure how to solve the problem...

Which instruction does the exception happen on? It could be memory access
problem.
On Oct 19, 2012 7:50 AM, "Marlon Smith" <
<email address hidden>> wrote:

> Question #211513 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/211513
>
> Marlon Smith gave more information on the question:
> Joey, is this issue you were thinking about this one?
>
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka12545.html
>
> I seem to be getting a hard fault a few instructions into the
> Reset_Handler, regardless of what the instructions are. If so, I'm not
> sure how to solve the problem...
>
> --
> You received this question notification because you are an answer
> contact for GCC ARM Embedded.
>

Hi Joey,

It doesn't happen on any particular instruction. I can change the startup code and it happens regardless.

I even tried chengbin's 4-step example on this thread, and it still doesn't run properly: https://answers.launchpad.net/gcc-arm-embedded/+question/201586

Marlon

Can it be debugging adapter problem?
On Oct 19, 2012 9:11 AM, "Marlon Smith" <
<email address hidden>> wrote:

> Question #211513 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/211513
>
> Status: Answered => Open
>
> Marlon Smith is still having a problem:
> Hi Joey,
>
> It doesn't happen on any particular instruction. I can change the
> startup code and it happens regardless.
>
> I even tried chengbin's 4-step example on this thread, and it still
> doesn't run properly: https://answers.launchpad.net/gcc-arm-
> embedded/+question/201586
>
> Marlon
>
> --
> You received this question notification because you are an answer
> contact for GCC ARM Embedded.
>

It could be; I'm looking into that as well.

Do you have a simple .elf file I could try loading to be sure? I've been looking around but haven't seen any online.

Ok I've confirmed it's not my debugger; I found another simple project and I can load it and step through the code.

I noticed something weird: when I step through my code in gdb I see an undefined instruction right in the middle of my assembly code. Here's the disassembly out of the compiler, and the list that GDB shows to match it:

marlons_led:
    movw r4, #49180
 426: f24c 041c movw r4, #49180 ; 0xc01c
    movt r4, #16388
 42a: f2c4 0404 movt r4, #16388 ; 0x4004
    mov.w r3, #320
 42e: f44f 73a0 mov.w r3, #320 ; 0x140
    str r3, [r4, #0]
 432: 6023 str r3, [r4, #0]

    movw r4, #45184
 434: f24b 0480 movw r4, #45184 ; 0xb080
    movt r4, #16388
 438: f2c4 0404 movt r4, #16388 ; 0x4004
    mov.w r3, #8388736
 43c: f04f 1380 mov.w r3, #8388736 ; 0x800080
    str r3, [r4, #0]
 440: 6023 str r3, [r4, #0]

0x426 <marlons_led> ldreq pc, [r12], #-588 │
   │0x42a <marlons_led+4> streq pc, [r4], #-708 │
   │0x42e <marlons_led+8> movvc pc, #1325400064 ; 0x4f000000 │
   │0x432 <marlons_led+12> vhadd.s8 d22, d11, d19 │
   │0x436 <marlons_led+16> vaddhn.i16 d16, q10, q0 │
   │0x43a <marlons_led+20> undefined instruction 0xf04f0404 │
   │0x43e <marlons_led+24> eorvs r1, r3, r0, lsl #7 │
   │0x442 <end_marlons_led> strdcs lr, [lr], -lr │
   │0x446 <end_marlons_led+4> strgt r4, [r0, #-5]! │
   │0x44a <end_marlons_led+8> stmdble r8!, {} │
   │0x44e <end_marlons_led+12> andcs r0, r0, r0 │
   │0x452 <end_marlons_led+16> bicseq r4, r2, r5 │
   │0x456 <end_marlons_led+20> andeq r0, r0, r0 │
   │0x45a <end_marlons_led+24> undefined instruction 0xffff0000 │
   │0x45e undefined instruction 0xffffffff │
   │0x462 undefined instruction 0xffffffff

Could that be part of the problem? Why do the instructions look different?

After loading your program onto target board, you can dump that section of binary back and comparing with the corresponding part of axf file. If there are different, then the downloading process might goes wrong.

BTW, you can refer to GDB manual for how to dump binrary.

Hoping this can help.

I tried dumping the output back from gdb, and it matches the original file generated from the compiler. I'm pretty sure my debug toolchain is working correctly.

Is there something that could be causing gcc to compile assembler code that the Cortex-M4 doesn't like?

Ok I found a demo binary file provided by Freescale, loaded it onto the board and it works! So my debug toolchain is solid.

I must be doing something wrong with the way I'm setting up my makefile, startup script, or linker script....

Was the wait state setup correctly?
On Oct 20, 2012 4:16 AM, "Marlon Smith" <
<email address hidden>> wrote:

> Question #211513 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/211513
>
> Marlon Smith gave more information on the question:
> Ok I found a demo binary file provided by Freescale, loaded it onto the
> board and it works! So my debug toolchain is solid.
>
> I must be doing something wrong with the way I'm setting up my makefile,
> startup script, or linker script....
>
> --
> You received this question notification because you are an answer
> contact for GCC ARM Embedded.
>