This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: using GDB without ROM Monitor


Hi Gary,

starting the target with the following flags:

in eCosHal:
- include gdb stubs in hal
   Macro: CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
   Enable: True

- include GDB external break support for stubs
   Macro: CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT
   Enable: True

- include GDB multi-threading debug support
   Macro: CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT
   Enable: True

- Start up type
Macro: CYGHAL_STARTUP
Value: ROM
- GDB serial port baud rate 115200


- Number of communication channels on the board 2 (gray)
   Macro: CYGNUM_HAL_VIRTUAL_VECTOR_COMM_CHANNELS
   Value: 2

- debug serial port 0
   Macro: CYGNUM_HAL_VIRTUAL_VECTOR_DEBUG_CHANNELS
   Value: 0

- Diagnostic serial port 0 (gray)
   Macro: CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNELS
   Value: 0

there is just a "+" on the debug port (uart0) and the target is starting normaly


if i write set_debug_traps (),like it is recommended in the generic-stub.c file, it works fine, too. But if i write breakpoint(); i get the same failure like: +h$T0athread:00000001;0f:08340d00;0d:385a0004;#ef after starting the target. The target never reaches the lines in the program bevor breakpoint(); but it reacts with

"c$T05thread:00000002;0f:b0370000;0d:ecdd0004;#4c"

on inputs over the uart0 port.

starting a thread with printf:
+h$T0athread:00000015;0f:8c9a0800;0d:f080022c;#5e

if the target is connected with the JTAGkey
+h$T0athread:00000001;0f:30350d00;0d:385a0004;#eb

Thanks alot,
Christian

Gary Thomas schrieb:

On 01/13/2011 08:22 AM, Christian Kraus wrote:

Gary Thomas schrieb:

On 01/12/2011 07:08 AM, Christian Kraus wrote:

Hallo,

We want to use the GDB Stub together with our application, we do not want to use the GDB/Redboot ROM Monitor
and we want to debug only one thread. While we debugging this thread, the others threads should not suspended or stopped.
The debugging should be done by GDB and Eclipse.
We do not exactly know if this is posible with ecos with the GDB.



Sorry, no. Once you are interacting via GDB, all else stops, interrupts, threads, etc.


We are still using ecos 2.0 release. We using the STR912 microcontroller. We have porting the ecos to this Controller by ourselves.


We have now include the GDB Stub support into the target. There was no error durring compilation.
After flashing the binary the target printed out some chars on the serial debug port.



That's the application telling you that it's ready to talk via the GDB protocol. Most likely, something like $O1234#99 which is an output string.

Then we start to connect to the target with GDB. First it seems that it works, but we get SIGTRAP error, after that
the Programm counter goes to 0 and after that nothing works any more.



More details are required to help much more.


Thank you very much for the fast reply.
And the information you gave to us helps for the first moment.

Here are more information about the problem. I think everything looks fine for the first moment, but we get some errors later:

i get the following output after starting the target:


+h$T0athread:00000001;0f:fcc80a00;0d:cc5a0004;#dc


then i try to set a GDB-Connection:


C:\bw.vendor\G5\enip\.release>arm-none-eabi-gdb -b 115200
GNU gdb (CodeSourcery Sourcery G++ Lite 2007q3-53) 6.6.50.20070821-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i686-mingw32 --target=arm-none-eabi".
For bug reporting instructions, please see:
<https://support.codesourcery.com/GNUToolchain/>.


(gdb) file enip.elf
Reading symbols from C:\bw.vendor\G5\enip\.release/enip.elf...done.
(gdb) target remote COM3
Remote debugging using COM3
0x000ac8fc in cyg_ether_ifattach (ifp=0x40008e8, bpf=<value optimized out>)
at c:/bw.vendor/ecos-2.0/packages/net/bsd_tcpip/current/src/sys/net/if_ether


subr.c:742
742 sdl = (struct sockaddr_dl *)ifa->ifa_addr;
Current language: auto; currently c
(gdb) c
Continuing.
[New Thread 1]

after typing c in the console one more i get the following error:


Program received signal SIGBUS, Bus error.
cyg_ether_ifattach (ifp=0x40008e8, bpf=<value optimized out>)
at c:/bw.vendor/ecos-2.0/packages/net/bsd_tcpip/current/src/sys/net/if_ether


subr.c:744
744 sdl->sdl_alen = ifp->if_addrlen;
(gdb) c
Continuing.


i checked the communication on the COM-Port. after i tried to connect the gdb with the target i get:


Port A = GDB
Port B = target

[Port A] 01.01.1970 01:01:09 $q
[Port B] 01.01.1970 01:01:09 $
[Port A] 01.01.1970 01:01:09 S
[Port B] 01.01.1970 01:01:09 T
[Port A] 01.01.1970 01:01:09 u
[Port B] 01.01.1970 01:01:09 0
[Port A] 01.01.1970 01:01:09 p
[Port B] 01.01.1970 01:01:09 a
[Port A] 01.01.1970 01:01:09 p
[Port B] 01.01.1970 01:01:09 t
[Port A] 01.01.1970 01:01:09 o
[Port B] 01.01.1970 01:01:09 h
[Port A] 01.01.1970 01:01:09 r
[Port B] 01.01.1970 01:01:09 r
[Port A] 01.01.1970 01:01:09 t
[Port B] 01.01.1970 01:01:09 e
[Port A] 01.01.1970 01:01:09 e
[Port B] 01.01.1970 01:01:09 a
[Port A] 01.01.1970 01:01:09 d
[Port B] 01.01.1970 01:01:09 d
[Port A] 01.01.1970 01:01:09 #
[Port B] 01.01.1970 01:01:09 :
[Port A] 01.01.1970 01:01:09 3
[Port B] 01.01.1970 01:01:09 0
[Port A] 01.01.1970 01:01:09 7
[Port B] 01.01.1970 01:01:09 0000001;0f:fcc80a00;0d:cc5a0004;#dc$T0athread:000000
[Port A] 01.01.1970 01:01:09 +
[Port B] 01.01.1970 01:01:09 01;0f:fcc80a00;0d:cc5a0004;#dc
[Port A] 01.01.1970 01:01:09 +$qSupported#37
[Port B] 01.01.1970 01:01:11 +$#00
[Port A] 01.01.1970 01:01:11 ++$Hc-1#09
[Port B] 01.01.1970 01:01:11 +$OK#9a
[Port A] 01.01.1970 01:01:11 +$qC#b4
[Port B] 01.01.1970 01:01:11 +$QC00000001#15
[Port A] 01.01.1970 01:01:11 +$qOffsets#4b
[Port B] 01.01.1970 01:01:11 +$#00
[Port A] 01.01.1970 01:01:11 +$?#3f
[Port B] 01.01.1970 01:01:11 +$S0a#e4
[Port A] 01.01.1970 01:01:11 +$Hg1#e0
[Port B] 01.01.1970 01:01:11 +$OK#9a
[Port A] 01.01.1970 01:01:11 +$g#67
[Port B] 01.01.1970 01:01:11
+$b26a12a501000000e83c0104e26a12a5e8080004d8080004246e0004d808000400000000fdffffff30000004bcb2000406000000cc5a000454140a00fcc80a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000#ee



[Port A] 01.01.1970 01:01:11 +$mac8fc,4#92 [Port B] 01.01.1970 01:01:11 +$000092e5#c5 [Port A] 01.01.1970 01:01:11 +$qSymbol::#5b [Port B] 01.01.1970 01:01:12 +$#00

and after typing c in the console:

[Port A] 01.01.1970 01:01:12 +$vCont?#49
[Port B] 01.01.1970 01:02:38 +$#00
[Port A] 01.01.1970 01:02:38 +$Hc0#db
[Port B] 01.01.1970 01:02:38 +$OK#9a
[Port A] 01.01.1970 01:02:38 +$C0a#d4
[Port B] 01.01.1970 01:02:38 +h$T0athread:00000001;0f:0cc90a00;0d:cc5a0004;#a7
[Port A] 01.01.1970 01:02:38 +$mac90c,4#5d
[Port B] 01.01.1970 01:02:38 +$0630c0e5#f6
[Port A] 01.01.1970 01:02:38 +$g#67
[Port B] 01.01.1970 01:02:38
+$de6a12a501000000e83c010406000000e8080004d8080004246e0004d808000400000000fdffffff30000004bcb2000406000000cc5a000454140a000cc90a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000d3000060#8a




This is telling you that your code already has an abort
condition (PC=0xfcc80a00).  You should examine the registers,
get a backtrace, etc. to figure out why it stopped where
it did.



--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]