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

GDB: Cannot access memory at address 0x1ffffffc

Hi,

I'm compiling the simple blinky example with no softdevice for an NRF51822 xxAA using GCC on linux. I can't get any LEDS to blink off the GPIOs, so I'm debugging with GDB.

According to GDB, addresses ranging from 0x1ffffffc down to 0x1fffffe4 are being accessed. This clearly won't work as ARM cortex M0 ram is mapped to start at 0x2000000.

Something's going wrong here and I can't figure it out.

This is my linker script:

/* Linker script to configure memory regions. */

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

MEMORY
{
  FLASH (rx) : ORIGIN = 0x0, LENGTH = 0x20000
  RAM (rwx) :  ORIGIN = 0x20000000, LENGTH = 0x4000
}

INCLUDE "gcc_nrf51_common.ld"

This is what my GDB session looks like:

GNU gdb (7.6.50.20131218-0ubuntu1+1) 7.6.50.20131218-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <gnu.org/.../gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<www.gnu.org/.../>.
Find the GDB manual and other documentation resources online at:
<www.gnu.org/.../>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/ajs/src/nRF51_SDK_9.0.0_2e23562/examples/peripheral/blinky/pca10031/blank/armgcc/_build/nrf51422_xxaa.out...expanding to full symbols...done.
Remote debugging using :1234
0xfffffffe in ?? ()
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/ajs/src/nRF51_SDK_9.0.0_2e23562/examples/peripheral/blinky/pca10031/blank/armgcc/_build/nrf51422_xxaa.out 
0x0000028e in Reset_Handler ()
(gdb) l
1	../../../../../libgloss/arm/crt0.S: No such file or directory.
(gdb) n
Single stepping until exit from function Reset_Handler,
which has no line number information.
Can't send signals to this remote system.  SIGSEGV not sent.
Cannot access memory at address 0x1ffffffc
0x000002ac in NMI_Handler ()
(gdb) l
1	in ../../../../../libgloss/arm/crt0.S
(gdb) n
Single stepping until exit from function NMI_Handler,
which has no line number information.
Cannot access memory at address 0x1ffffffc
0x000002ae in HardFault_Handler ()
(gdb) l
1	in ../../../../../libgloss/arm/crt0.S
(gdb) n
Single stepping until exit from function HardFault_Handler,
which has no line number information.
Cannot access memory at address 0x1ffffffc
0x000002b0 in SVC_Handler ()
(gdb) l
1	in ../../../../../libgloss/arm/crt0.S
(gdb) n
Single stepping until exit from function SVC_Handler,
which has no line number information.
Cannot access memory at address 0x1ffffffc
0x000002b2 in PendSV_Handler ()
(gdb) l
1	in ../../../../../libgloss/arm/crt0.S
(gdb) n
Single stepping until exit from function PendSV_Handler,
which has no line number information.
Cannot access memory at address 0x1ffffffc
0x000002b4 in SysTick_Handler ()
(gdb) l
1	in ../../../../../libgloss/arm/crt0.S
(gdb) n
Single stepping until exit from function SysTick_Handler,
which has no line number information.
Cannot access memory at address 0x1ffffffc
0x000002b6 in WDT_IRQHandler ()
(gdb) l
1	in ../../../../../libgloss/arm/crt0.S
(gdb) n
Single stepping until exit from function WDT_IRQHandler,
which has no line number information.
Cannot access memory at address 0x1ffffffc
atexit (fn=0x0 <__Vectors>) at ../../../../../../newlib/libc/stdlib/atexit.c:64
64	../../../../../../newlib/libc/stdlib/atexit.c: No such file or directory.
(gdb) l
59	in ../../../../../../newlib/libc/stdlib/atexit.c
(gdb) n
Cannot access memory at address 0x1fffffe4
(gdb) l
59	in ../../../../../../newlib/libc/stdlib/atexit.c
(gdb) n
65	in ../../../../../../newlib/libc/stdlib/atexit.c
(gdb) l
60	in ../../../../../../newlib/libc/stdlib/atexit.c
(gdb) n
66	in ../../../../../../newlib/libc/stdlib/atexit.c
(gdb)

output from make:

# make
rm -rf _build
echo  Makefile
Makefile
mkdir _build
Compiling file: system_nrf51.c
Compiling file: main.c
Compiling file: nrf_delay.c
Compiling file: gcc_startup_nrf51.s
Linking target: nrf51422_xxaa.out
make[1]: Entering directory `/home/ajs/src/nRF51_SDK_9.0.0_2e23562/examples/peripheral/blinky/pca10031/blank/armgcc'
Preparing: nrf51422_xxaa.bin
Preparing: nrf51422_xxaa.hex

   text	   data	    bss	    dec	    hex	filename
   1540	   1064	      0	   2604	    a2c	_build/nrf51422_xxaa.out

make[1]: Leaving directory `/home/ajs/src/nRF51_SDK_9.0.0_2e23562/examples/peripheral/blinky/pca10031/blank/armgcc'
Parents
  • Using 'n' to single step out of the reset_handler() doesn't make much sense because the reset handler isn't entered as a normal function and doesn't have a return address on the stack. I'd think the 0x1ffffffc is a bit of a red herring and is just GDB trying to read stuff at random addresses trying to figure out where the current code is going to return to, which it isn't.

    Once it fails that you appear to end up somewhere in one of the handlers, the hardfault one from the look of it, perhaps as a result of GDB accessing memory it shouldn't. You continue trying to 'n' and it continues to randomly increment the PC, at this point you're not really debugging, GDB has lost the plot.

    Using 's' to step might get you a bit further, putting a breakpoint in SystemInit() or main() would be better still.

Reply
  • Using 'n' to single step out of the reset_handler() doesn't make much sense because the reset handler isn't entered as a normal function and doesn't have a return address on the stack. I'd think the 0x1ffffffc is a bit of a red herring and is just GDB trying to read stuff at random addresses trying to figure out where the current code is going to return to, which it isn't.

    Once it fails that you appear to end up somewhere in one of the handlers, the hardfault one from the look of it, perhaps as a result of GDB accessing memory it shouldn't. You continue trying to 'n' and it continues to randomly increment the PC, at this point you're not really debugging, GDB has lost the plot.

    Using 's' to step might get you a bit further, putting a breakpoint in SystemInit() or main() would be better still.

Children
No Data
Related