[ECOS] gdb output in RAM build

Lambrecht Jürgen J.Lambrecht@TELEVIC.com
Wed Jun 4 06:40:00 GMT 2008


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



More information about the Ecos-discuss mailing list