[ECOS] Serial communication issues

[ECOS] Serial communication issues

[Andreas Stenius]

Hi,

I've been struggling with this for a few days now, and are initially
looking for anyone that recognizes any of this, or maybe have some
insights to what may be going on.

I'm working on a project based on a custom hardware fitted with a
AT91R40008, at 40Mhz.

The application is debugged using GDB connected with a JTAG dongle to
the board, and this works fine.

However, when the application is running from flash using a ROM
configuration, I have issues on /dev/ser1.
I have a console running on /dev/termios0 (connected to /dev/ser0),
and this runs fine in both RAM and ROM.

The issues on ser1 is that after I send a request (two bytes) the
reply is not always received correctly (or at all, not sure which
yet).
However, whenever I enable some diagnostic printouts around the calls
to cyg_io_write/cyg_io/read, it works ok, so as soon as I affect the
timing of the send/read calls, it works.
The reply is always consistent and correct on the wire (confirmed with
oscilloscope).

I have setup ser1 to operate in a non-blocking mode (and no termios on
this channel).
I'll dig in deeper trying to solve this, just wanted to throw this out
here in case someone recognizes any of this.. ;)

Oh, and running a eCos version from cvs, 2012-05-27.

//Andreas

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

[ECOS] Re: Serial communication issues

[Andreas Stenius]

OK, not 100% clear, but I've narrowed it down to the interrupt driven
DMA receiver in at91_serial.c.

I used the default values for the HW serial driver, with a receive
buffer of 128 bytes, and a receive chunk size of 1 byte.

After adding a bunch of CYG_TRACE calls, which didn't affect the
timings too much, I captured a trace where it had dropped two bytes.

Analyzing the trace and source, I suspect that the ISR/DSR handling of
the DMA receiver isn't glitch free when done in the midst of incoming
data.

With this knowledge, I changed my receive chunk size to 6 bytes, and
the issue has gone away, for this particular use case. Not yet sure if
it is going to show up again later or not.. :/


Btw, there are a few rough edges in the trace handling when set to
halt after filling the trace buffer.
First, when printing a halted trace buffer (i.e. it is full), it will
go into an endless loop.
This from the fact that the loop variable i is set to 0 before the end
test when it has reached the last entry.
Moving the if (i == BUFFER_SIZE) test to the head of the loop instead
of at the bottom solves this (so the while test is done first, then
the if test).

Secondly, there is no way to restart the tracing once it has been
halted. I find this rather limiting, so I dropped the old_halted
variable in cyg_trace_print() so that the trace is restarted after
printing the contents of the trace buffer.

I'll consider posting this as a patch to the bugzilla database...

Cheers,
Andreas

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