This is the mail archive of the ecos-discuss@sourceware.org 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  
> <sergei.gavrikov@gmail.com> 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
> >
> >cdl_option CYGHWR_HAL_ARM_LPC2XXX_IDLE_PWRSAVE {
> >    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.

IMHO, it is a JTAG issue, jtag cannot halt CPU. Usually, they recommend
that your early startup has a loop in assembler during a few time to
give a chance JTAG halt CPU. A few ms it's enougth. You can put this in
your hal_platform_startup.s (before any initialization, it should be
just a loop in asm).

> 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

diag_printf() is good for asserts, diagnostic output, etc., i.e. for
debugging only. What is a reason to use it inside the threads?

every plf. diagnostic "putc" is something like this blocking loop:

	do {
	    // check UART status
	} while (!can_send);


It's not good for multi-threads applications. It blocks eCos, so, use
printf() inside the threads, interrupt-driven and non-blocking serial
I/O. Use a mutex to share printf() between the threads. I do not think
that eCos's the floating-points-less printf() is heavy stuff. Robert,
that is just my thoughts about your implementation. This is not JTAG
related things.


Sergei



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


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