This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Thread messages problem.
- To: "Jonathan Larmour" <jlarmour at redhat dot com>
- Subject: RE: [ECOS] Thread messages problem.
- From: <felixwong at i-technologies dot cc>
- Date: Tue, 30 Oct 2001 11:11:13 +0800
- Cc: "Ecos-Discuss" <ecos-discuss at sources dot redhat dot com>
Hello Jonathan,
I tried to remove the "debugging messages for the kernel device initialisation" part,
only debug message for my own harddisk device was enabled. Then the $T messages
gone & the system runs without any error.
However, within my file system where I print out the debug info using "diag_printf" to print
test values to "ser0" of my EB40, the similar message appears. Have you ever met the
same problem when you diag_print lots of debug messages using your EB40 board?
Is it related to the serial port buffer (which I set to 1024 byte)? Or anywhere I can set my
default stack size in eCos configuration tools?
FW.
-----Original Message-----
From: jlarmour@worf.jifvik.org [mailto:jlarmour@worf.jifvik.org]On Behalf Of Jonathan Larmour
Sent: Tuesday, October 30, 2001 10:56 AM
To: felixwong@i-technologies.cc
Cc: Ecos-Discuss
Subject: Re: [ECOS] Thread messages problem.
felixwong@i-technologies.cc wrote:
>
> I am writing a hard disk device driver for eCos system on the Atmel EB40 board
> with my specific ATA interface hardware. In debug process, I enabled the
> CYGDBG_IO_INIT keyword for debugging messages in serial port #0 (diag_printf).
>
> The problem I met was quite annoying, some thread messages was displayed on
> the serial port #0 terminal. Sometime appear just after 1 or 2 devices initialized,
> another time appear after all devices initialized. They look like:
> $T05thread:00000001;0f:ac680402;0d:9c680402;#03
> $T05thread:00000001;0f:84680402;0d:68680402;#7d
> on the screen(of terminal program). The the program cannot proceed to the
> "main" where I set my breakpoint there.
That shouldn't happen. That implies the stub stopped, e.g. because it hit a
breakpoint. It's intriguing that the values you cite all end in 680402, yet
for a $T GDB packet those are the PC and SP. I think you might be
encountering stack corruption, or stack overflow.
Jifl
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine