public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] using GDB without ROM Monitor
@ 2011-01-12 14:09 Christian Kraus
  2011-01-12 14:18 ` Gary Thomas
  0 siblings, 1 reply; 4+ messages in thread
From: Christian Kraus @ 2011-01-12 14:09 UTC (permalink / raw)
  To: ecos-discuss

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.

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

How anyone help use with our Problem.

Best regards
Christian Kraus



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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ECOS] using GDB without ROM Monitor
  2011-01-12 14:09 [ECOS] using GDB without ROM Monitor Christian Kraus
@ 2011-01-12 14:18 ` Gary Thomas
       [not found]   ` <4D2F18AE.8030600@bihl-wiedemann.de>
  0 siblings, 1 reply; 4+ messages in thread
From: Gary Thomas @ 2011-01-12 14:18 UTC (permalink / raw)
  To: Christian Kraus; +Cc: ecos-discuss

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.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ECOS] using GDB without ROM Monitor
       [not found]   ` <4D2F18AE.8030600@bihl-wiedemann.de>
@ 2011-01-13 15:41     ` Gary Thomas
  2011-01-14 13:50       ` Christian Kraus
  0 siblings, 1 reply; 4+ messages in thread
From: Gary Thomas @ 2011-01-13 15:41 UTC (permalink / raw)
  To: Christian Kraus; +Cc: eCos Discussion

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.

-- 
Please keep your replies on the mailing list(s) so that all
may benefit.  Private support is available under contract
from various agents, including MLB Associates.  Private
email to me without a contract will be ignored.

------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------



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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ECOS] using GDB without ROM Monitor
  2011-01-13 15:41     ` Gary Thomas
@ 2011-01-14 13:50       ` Christian Kraus
  0 siblings, 0 replies; 4+ messages in thread
From: Christian Kraus @ 2011-01-14 13:50 UTC (permalink / raw)
  To: Gary Thomas; +Cc: eCos Discussion

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-01-14 13:50 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-12 14:09 [ECOS] using GDB without ROM Monitor Christian Kraus
2011-01-12 14:18 ` Gary Thomas
     [not found]   ` <4D2F18AE.8030600@bihl-wiedemann.de>
2011-01-13 15:41     ` Gary Thomas
2011-01-14 13:50       ` Christian Kraus

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).