public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Tom B" <tom.i.burns@gmail.com>
To: ecos-discuss@ecos.sourceware.org
Subject: [ECOS] LPC2214 Porting issue: Garbage data on Serial Console
Date: Fri, 02 Jun 2006 16:55:00 -0000	[thread overview]
Message-ID: <671c20540606020955v373fc75eu64ed910bfe1b982c@mail.gmail.com> (raw)

Hello eCos list,

  In my effort to port eCos to a LPC2214-based board, I'm running into
some troubles with the serial port.  When I load Redboot and execute
it, I get garbage data outputted on the serial port, about 80 bytes.
The execution then gets stuck attempting to read a character from the
console - here is the backtrace at this point:

#0  hal_clock_read (pvalue=0x8101afbc)
    at /opt/ecos/ecos-cvs/packages/hal/arm/lpc2xxx/var/current/src/lpc2xxx_misc.
c:124
#1  0x81006ac0 in delay_us (usecs=0x64)
    at /opt/ecos/ecos-cvs/packages/hal/common/current/src/hal_if.c:226
#2  0x810126fc in cyg_hal_plf_serial_getc_timeout (__ch_data=0x81018cdc,
    ch=0x8101b04f "\201dù\001\201\001") at hal_if.h:639
#3  0x8100fe6c in mon_read_char_with_timeout (
    c=0x8101b04f "\201dù\001\201\001") at hal_if.h:335
#4  0x81010114 in $a ()
    at /opt/ecos/ecos-cvs/packages/redboot/current/src/io.c:386
#5  0x81010114 in $a ()
    at /opt/ecos/ecos-cvs/packages/redboot/current/src/io.c:386

The key is frame 2, as 1 and 0 are just delaying before polling the
device again for data.  If I attempt to enter characters, it is not
detected by the program.

If I build eCos as a library, and build and link a "hello world" app,
I get no serial output, but instead for some reason my call to printf
prompts a chain of events that ends up calling cyg_hal_plf_serial_getc
(which I find odd, since I'm telling it to print to the console, not
read from the console..).  Here is the stack trace when it is waiting
for a character, initially prompted by a call to printf:

(arm-gdb) bt
#0  cyg_hal_plf_serial_getc_nonblock (__ch_data=0xe0010000,
    ch=0x81027cbb "_\217")
    at /opt/ecos/ecos-cvs/packages/hal/arm/lpc2xxx/var/current/src/hal_diag.c:12
4
#1  0x81012a38 in cyg_hal_plf_serial_getc (__ch_data=0x81021298)
    at /opt/ecos/ecos-cvs/packages/hal/arm/lpc2xxx/var/current/src/hal_diag.c:13
7
#2  0x81003608 in cyg_hal_diag_mangler_gdb_flush (__ch_data=0xe0010000)
    at hal_if.h:311
#3  0x81003a08 in hal_if_diag_write_char (c=0x0) at hal_if.h:305
#4  0x81015c44 in haldiag_putc (chan=0xe0010000, c=0xbb)
    at /opt/ecos/ecos-cvs/packages/io/serial/current/src/common/haldiag.c:114
#5  0x81015200 in serial_write (handle=0xe0010000, _buf=0x81027cbb,
    len=0x81027d7c)
    at /opt/ecos/ecos-cvs/packages/io/serial/current/src/common/serial.c:331
#6  0x81012f78 in cyg_io_write (handle=0xe0010000, buf=0x81027cbb, len=0x60)
    at /opt/ecos/ecos-cvs/packages/io/common/current/src/iosys.c:178
#7  0x81015978 in tty_write (handle=0xe0010000, _buf=0x81027cbb,
    len=0x81027e00)
    at /opt/ecos/ecos-cvs/packages/io/serial/current/src/common/tty.c:190
#8  0x81012f78 in cyg_io_write (handle=0xe0010000, buf=0x81027cbb, len=0x60)
    at /opt/ecos/ecos-cvs/packages/io/common/current/src/iosys.c:178
#9  0x8101156c in Cyg_StdioStream::flush_output_unlocked (this=0x81025b14)
    at io.inl:229
#10 0x81012300 in Cyg_StdioStream::write (this=0x81025b14,
    buffer=0x8101c9eb "", buffer_length=0x0, bytes_written=0x81027f08)
    at /opt/ecos/ecos-cvs/packages/language/c/libc/stdio/current/src/common/stre
am.cxx:701
#11 0x81006534 in $a ()
    at /opt/ecos/ecos-cvs/packages/language/c/libc/stdio/current/src/output/vfnp
rintf.cxx:277
#12 0x81006534 in $a ()
    at /opt/ecos/ecos-cvs/packages/language/c/libc/stdio/current/src/output/vfnp
rintf.cxx:277
(arm-gdb)

Again, entering a character does not force the application to exit the
getc call (I am sure of this, I set a breakpoint following the getc).

I know that the serial port and interface to the computer is working
fine, as I've tested both with loopback devices and also I have code
that manually manipulates the LPC registers to interact with the
serial port, and both work fine.

Anyone have any suggestions on how I can debug this problem, or ideas
on what's causing it?

Cheers,
Tom Burns

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

             reply	other threads:[~2006-06-02 16:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-02 16:55 Tom B [this message]
2006-06-05 17:08 ` [ECOS] " Tom B
2006-06-06 10:37   ` [ECOS] Dynamic IP/DHCP/Routing the 'right way' Laurie Gellatly
2006-06-06 10:56     ` Andrew Lunn
2006-06-06 11:09       ` Laurie Gellatly
2006-06-06 11:19         ` Andrew Lunn
2006-07-28 21:30           ` Joe Porthouse
2006-07-28 21:59             ` Laurie Gellatly
2006-07-29  1:52               ` Joe Porthouse
2006-07-31  7:32                 ` Laurie Gellatly
2006-06-06 11:16   ` [ECOS] eCos meets SHTTPD (web server) Laurie Gellatly

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=671c20540606020955v373fc75eu64ed910bfe1b982c@mail.gmail.com \
    --to=tom.i.burns@gmail.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).