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, 07 Apr 2009 16:01:35 +0200, Sergei Gavrikov <> wrote:

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:

>>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
>>Well, it's ugly, but, if you do not want to mess up 3.0 sources, it
>>be a way.
>>Perhaps, eCos veterans know about another way.
>It's just for reference how it was done for lpc2xxx variants:
>So, I can use
> user_value 0
>for my target to disable that "odd" mode. Certainly it can be disabled
>with `configtool' too.

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
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
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).

==> The BDI is configured to stop the target when it comes out of reset. And that it does wunderfully. I then click the run button and that's were the problems start :-(

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

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.


Hi Sergei

Well, I used to have printf-statements in all my programs. But since working with the new arm-eabi toolchain, I found that all my programs crash in this printf statement. I reported this in the arm_gnu forum, but got no useful answer. :-(

Right now I have kicked out all diag_printf statements in the thread and put printf instead - No output in no case.
Then I changed it to fprintf(... and already the statement

fuser = fopen("/dev/ser1", "w");

comes back with fuser == 0 - even so I enabled ser0 and ser1 - the interrupt driven version at91serial - in configtool ...

Something very basic must be wrong in my case. If only I knew what?????? :-(

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]