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 <[EMAIL PROTECTED]>: >> 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
