This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Debugger fails when I add kernel support
- From: Sergei Gavrikov <sergei dot gavrikov at gmail dot com>
- To: Robert Brusa <bob dot brusa at gmail dot com>
- Cc: MailingList: ecos-discuss <ecos-discuss at ecos dot sourceware dot org>;
- Date: Mon, 6 Apr 2009 22:16:00 +0300
- Subject: Re: [ECOS]Debugger fails when I add kernel support
- References: <op.ury9w114keg3uf@localhost>
On Mon, Apr 06, 2009 at 08:35:22PM +0200, Robert Brusa wrote:
> Hi
> I have written a small program to clear the memory (at91sam7x512-based
> board). Actually it works fine, but I can not debug it. The program uses
> cyg_user_start to initialize as task as follows:
>
> #include <cyg/kernel/kapi.h> /* All the kernel specific stuff */
> #include <cyg/infra/diag.h> // bring in e. g. cyg_type.h
>
> void cyg_user_start(void)
> {
> diag_printf("\nmemset start");
> cyg_thread_create(TASK_PRIO, mytask, (cyg_addrword_t) 0, "mytask",
> (void*) &stack, STACKSIZE, &thread, &thread_obj);
> diag_printf("\ncreate done\n");
> cyg_thread_resume(thread);
> diag_printf("\nresume done\n"); // never
> }
>
> I am working with Eclipse Ganymede/CDT conned via LAN to a BDI2000 JTAG
> device. When setting a breakpoint at diag_printf, the console output (see
> attachment) tells me it is reached, but no variables are displayed and
> the system can no longer be debugged (timeout). Having a closer look at
> the console output, it seams to me that gdb-command 104 looks suspicous.
> addr 0x000000 is just plain wrong.
>
> I also have a similar program that does not use a task, but instead
> mytask is replaced by a procedure - and hence kapi.h is not included. But
> all the rest is the same - especially the same ecos is used to build the
> program. With this simpler program - the debuggin works fine. I do not
> understand why.
> Robert
It's just a guess: It's possible that reason can be in an idle thread
stuff. The second version has no threads, hasn't it? And you debug the
version smoothly. So, be sure that HAL_IDLE_THREAD_ACTION does not turn
a power save mode (it is bad medicine for JTAG debugging). Well, it's
just a guess.
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