[ECOS] Re: LPC2214 Porting issue: Garbage data on Serial Console

Tom B tom.i.burns@gmail.com
Mon Jun 5 17:08:00 GMT 2006

An update:  I fixed the output problem in Redboot and now get the
Redboot header during initialization as I should - the problem was
that I had the wrong clock input defined so the math for calculating
delays was incorrect, resulting in the wrong baud rate.
Unfortunately, Redboot still does not recognize input from the serial

As well, the second stack trace is still occuring when I try to do a
printf while just linking against the target library.

Any ideas?


On 6/2/06, Tom B <tom.i.burns@gmail.com> wrote:
> 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

More information about the Ecos-discuss mailing list