[ECOS] gdb output in RAM build

[ECOS] gdb output in RAM build

[Jürgen Lambrecht]

Hello,
 
my RAM build (redboot or ecos RAM application) prints this:
 
$T050f:0000f071;0d:1c9d0320;#81
 
When I hit '+' it prints the next message, mostly always the same.
Referring to 
http://sourceware.org/ml/ecos-discuss/2006-10/msg00023.html, I'm quite 
sure this is GDB output.
But all my GDB options are disabled (searching through ecos.ecc). (I use 
a JTAG debugger).
When I debug with gdb-jtag, it looks like the code is in ROM.

Maybe this option causes the problem?:
  cdl_option CYGSEM_HAL_USE_ROM_MONITOR {
      # Flavor: booldata
      user_value 1 Generic
  };
 
Has anybody a clue?
 
Kind regards,
Jürgen
 

P.S.: I have already sent this  mail yesterday at 18:48, but from a 
different PC using Outlook - maybe Outlook messages are by default put 
in a spam folder ;-)


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

Re: [ECOS] gdb output in RAM build

[Pieter-Jan Busschaert]

2008/5/29 Jürgen Lambrecht <J.Lambrecht@televic.com>:
> Hello,
>
> my RAM build (redboot or ecos RAM application) prints this:
>
> $T050f:0000f071;0d:1c9d0320;#81


Do you have an other bootloader on the board? In our case, this is
printed from our (ROMRAM) redboot when a processor-exception happens
in our (RAM) ecos/userprogram. Look in
hal/common/current/src/generic-stub.c, function "send_t_packet". It
first calls "__build_t_packet", which is in
hal/common/current/src/hal-stub.c

There you can see the format is :

T <2 digits : signal number> <2 digits : PC reg number> : <PC reg
contents> ; <2 digits : SP reg number> : <SP reg contents> ; # <CRC>

PC = program counter
SP = stack pointer

There is also code to display the thread that was active, but as (in
our case) it's redboot who prints this information, there is no notion
of threads anymore at that point. We did add code there to print a
complete stack + a program-counter-backtrace (this is possible if you
have the stackpointer and know your hardware's convention for
stackframes).

This file is compiled in when you enable
CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS (see
hal/common/current/cld/debugging.cdl).


kind regards,

Pieter-Jan

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

Re: [ECOS] gdb output in RAM build

[Lambrecht Jürgen]

Hello Pieter-Jan,

It is indeed our Redboot ROM that had CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS enabled.
I disabled them, but enabled CYGHWR_HAL_ARM_DUMP_EXCEPTIONS instead to see the exceptions in "human" language instead of "GDB" language.

Thanks,
Jürgen


Pieter-Jan Busschaert wrote:
> 2008/5/29 Jürgen Lambrecht <J.Lambrecht@televic.com>:
>> Hello,
>>
>> my RAM build (redboot or ecos RAM application) prints this:
>>
>> $T050f:0000f071;0d:1c9d0320;#81
>
>
> Do you have an other bootloader on the board? In our case, this is
> printed from our (ROMRAM) redboot when a processor-exception happens
> in our (RAM) ecos/userprogram. Look in
> hal/common/current/src/generic-stub.c, function "send_t_packet". It
> first calls "__build_t_packet", which is in
> hal/common/current/src/hal-stub.c
>
> There you can see the format is :
>
> T <2 digits : signal number> <2 digits : PC reg number> : <PC reg
> contents> ; <2 digits : SP reg number> : <SP reg contents> ; # <CRC>
>
> PC = program counter
> SP = stack pointer
>
> There is also code to display the thread that was active, but as (in
> our case) it's redboot who prints this information, there is no notion
> of threads anymore at that point. We did add code there to print a
> complete stack + a program-counter-backtrace (this is possible if you
> have the stackpointer and know your hardware's convention for
> stackframes).
>
> This file is compiled in when you enable
> CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS (see
> hal/common/current/cld/debugging.cdl).
>
>
> kind regards,
>
> Pieter-Jan
>


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