This is the mail archive of the 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: Debugger fails when I add kernel support

On Tue, Apr 07, 2009 at 02:58:44PM +0200, Robert Brusa wrote:
> On Mon, 06 Apr 2009 23:39:24 +0200, Sergei Gavrikov  
> <> wrote:
> ..<cut>
> >>Robert, of course, the right way is to define own macro (= CDL rule) in
> >>the plf's stuff. But, that's not possible without a tweaking plf's code.
> >>I thought about a froud hack: to add something like the below in CFLAGS
> >>
> >>    -D"HAL_IDLE_THREAD_ACTION(x)={}"
> >>
> >>Well, it's ugly, but, if you do not want to mess up 3.0 sources, it  
> >>would
> >>be a way.
> >>
> >>Perhaps, eCos veterans know about another way.
> >>
> >
> >It's just for reference how it was done for lpc2xxx variants:
> >packages/hal/arm/lpc2xxx/var/current/include/var_arch.h:63
> >
> >So, I can use
> >
> >    user_value 0
> >};
> >
> >for my target to disable that "odd" mode. Certainly it can be disabled
> >with `configtool' too.
> >
> >Sergei
> Sergei, I did it with brutal force: I modified the lines inside var_arch.h
> in directory ecos/packages/hal/arm/at91/var/current/include such that the  
> macro
> HAL_IDLE_THREAD_ACTION(_counter_) is no longer generated. Then I created a  
> new ecos and linked my little project with this new ecos. The results are  
> mixed:
> a) As before, when switching power on with no JTAG debugger (BDI2000)  
> connected, the program launches and works fine.
> b) With the JTAG debugger connected, I am no longer in a position to  
> launch it with the BDI go 0 command (via telnet). No output at all.
> c) I can set breakpoints in cyg_user_start and the output of the  
> diag_printf statement in this routine appear - but
>    the output of the diag_printf routines in the thread created and  
> resumed from this reoutine do not appear - although I can catch
>    breakpoints in this thread.
> Not a very clear situation. Do you have a good idea? Thanks and regards
>    Robert


As I did promise I tried to reproduce your issue. My stuff was: eCos
3.0, OpenOCD (I built it this morning from SVN), parallel JTAG wiggler
from Olimex, CPU: ARM7TDMI-S (NXP LPC2294), board: Olimex LPC-H2294
header board.

I built eCos as I do it as well for tests using ecosconfig, template was
default. Only 2 imports were applied: 

cdl_component CYG_HAL_STARTUP {user_value ROM};
cdl_option CYGHWR_HAL_ARM_LPC2XXX_IDLE_PWRSAVE {user_value 0};

I reset the board, ran OpenOCD (see screenlog.0.txt) and did load a
built `twothreads' example. There is a full GDB session in the log. I
could stop a run at the outputs and before a start of a kernel and then.
All ouput will appear in minicom as I could expect. BTW, by default,
printf uses hal_if_diag_write_char(). See the log. I could output and
alone character and whole lines using breakpoints. ^C works as I could
expect too.

Yet another thing, if you could see, `serial' example uses printf(). BUT,

$ arm-eabi-nm examples/serial | grep -E '(printf|putc|_diag)'
00001cf8 t _GLOBAL__I.10100_diag_write_char
00001d24 t _ZL16_diag_write_charcPPv
8100027c d _ZL5_putc
00001ec8 t _ZL8_vprintfPFvcPPvES0_PKcS_
00005120 T cyg_hal_plf_serial_putc
00002a00 T diag_printf
00004eb8 T fputc
0000167c T hal_if_diag_init
000016bc T hal_if_diag_read_char
00001880 T hal_if_diag_write_char
00001244 t haldiag_putc
00004eb8 W putc
810002b8 D tty_io_diag
81003050 b tty_private_info_diag

There is no printf! Using CLI tools (arm-eabi-gdb) I at once noticed
that I cannot set a breakpoint on printf. And your IDE as I could see in
your pastes quite eats mice's breakpoints. AFAIR, I saw there

info threads
info sharedlibs

IDE shocks these requests the GDB for embedded. You set breakpoint, but,
program run. And I thought, that you can try `nm' on that your ELF to
check is there printf in text segment.  Well, it's just a guss only.

Certainly, when I ran `serial' I used stops on hal_if_diag_write_char().

So, what's difference in our environments

a) different JTAGs
b) CLI against IDE
c) Linux against Cygwin
d) different targets

and what's the same:

eCos 3.0 release.

I have no more ideas.


Attachment: screenlog.0.txt
Description: Text document

Before posting, please read the FAQ:
and search the list archive:

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