Re: [ECOS] Linux Synthetic target device support!

[Jesper Skov <jskov at cygnus dot co dot uk>]

>>>>> "Mohammed" == Mohammed Illyas Mansoor <mansoor@cdotb.ernet.in> writes:

Mohammed> Mohammed Illyas Mansoor wrote:
>>  serial3 is passing only if BINARY data is within 120 range
>> ser_filter is timing out if data is more than 120.  <cut> [f] 0000
>> 40 42 49 4e 41 52 59 3a '@BINARY:' [f] 0008 31 32 38 3a 31 21
>> .. .. '128:1!'  [f] Dispatching command BINARY.  [f] **** Timed out
>> while reading -- resuming as null filter [f] Data received 127
>> bytes (of 1) from target: </cut>

Mohammed>     This is happening only for the MODE_EOP_ECHO option in
Mohammed> binary cmd, I was able to send data upto 65536 in NO_ECHO
Mohammed> option.


Then it's clearly a problem with the driver's receive part. EOP_ECHO
means that the test will send some data to the host which is returned
at EOP (end-of-package).

So:

 target sends 128 bytes
 ser_filter returns the 128 bytes
 for some reason the serial driver hangs/crashes while receiving the
 128 bytes.

It may be because of lost bytes (performance problem, FIFO overflow
(assuming a FIFO is used), or similar), or maybe some array doesn't
have the proper size.

If the test didn't receive all the 128 bytes (i.e., lost bytes) it
should be able to recover and print out a FAIL. But there may be some
subtle bug in the testing code that prevents that... 




Mohammed> I was running ser_filter with the below options.
Mohammed> $./ser_filter -n -t -c -S /dev/ttyS0 9600

Mohammed> If I turned on gdb also I get the display from test programs
Mohammed> as "host side harness not detected"

I assume you mean when using the '-g' option? I don't have time to
look at the problem now, I'm afraid. But I think the latter versions
of the ser_filter ignores that option due to some interal
reorganization.

Since your version behaves differently, it must be an older version of
the code. The option should just cause all traffic from GDB to be
displayed on the console as well - it should have no effect on the
semantics of the testing infrastructure... So I guess there may be
another bug hiding somewhere.

Jesper