Discussion:
unknown
1970-01-01 00:00:00 UTC
Permalink
Hope anyone understand/visualize this, and help me can rectify the problem.
--
*Kuldeep Singh Dhaka*
+91-8791676237
Programmer, Open Source, Embedded System, Entrepreneur, System
Administrator, Animal Lover, Web Developer, Learner.
My GnuPG Public Key
<http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x23816C5609DC7E26>
Fork Me <http://github.com/kuldeepdhaka>
Bitcoins Accepted.

--------------020102010508090205080405
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
<head>

<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Howdy guys,<br>
Im facing a weird problem.<br>
i have a ST uC (FS usb) that send data of ADC (12 bit) at 176Kilo
samples at bInterval=1; (2bytes for 1 sample)<br>
ie 352byte isochronous endpoint requested every 1ms<br>
<br>
when i request 1000 packets (each of 352 bytes), i received 8byte
garbage value (mostly 0x00) at the end of the 999th packet (assuming
packet index start from 0).<br>
when i request 500 packets (each of 352 bytes), i received 8byte
garbage value (mostly 0x00) at the end of 499th packet.<br>
when i request 100 packets (each of 352 bytes), i received 8byte
garbage value (mostly 0x00) at the end of 99th packet.<br>
when i request 10 packets (each of 352 bytes) i received 8byte byte
garbage value (mostly 0x00 | non-zero on offset 1 byte of garbage
start) at the end of 9th packet. (non-zero garbage value position is
352 - 8 + 1).<br>
<br>
since, the garbage position shits as number of packets variate, so i
can assume that the device is successfully sending each packet.<br>
(and the packet count also not known to device, it very unlikely
that this will be related to device).<br>
(even if the problem is in device, the problem should occur in each
packet or some multiple version, why every-time error position is
similar)<br>
<br>
i can see plotting bumps, or 4 samples are garbage after the
accumulated packets are plotted. (qcustomplot + qt + libusbx)<br>
im reading sine wave using the ADC so the problem can be seen
visually.<br>
plotting on a 10second time-line, request 1000 packets in one
callback (1second data), i see 10 points inconsistent, (and after
zooming to any of the point, i can see that the point is made up of
4 samples that are always garbage).<br>
<br>
for 1000 packets (and 10second timeline) i see 10 inconsistent
points (all 0V)<br>
for 100 packets (and 10second timeline) i see 50 inconsistent points
(all 0V),<br>
for 10 packets (and 10 second timeline) i see 100 * 10 inconsistent
points (first is usually 40 volts (max voltage is 3V), and all
others are 0V)<br>
<br>
plotting approch: start plotting from 0th position, and when reach
the end of memory, again start plotting from 0th position, this is
how i was able detect that the problem (that it is at the end of
accumulated packets of one callback). (garbage point are always at
constant position)&nbsp; <br>
<br>
another test:<br>
i wrote pre-defined bytes (also that would never be send by device)
to the allocated buffer buffer, before submiting the iso packets
request, and after the callback, the memory was garbage (last 8byte
were not equal to the pre-defined bytes). so the memory was actually
being incorrectly written written by device, or kernel or libusb.<br>
<br>
but since based on the assumption the problem is not from device,
problem should be kernel or libusb.<br>
<br>
[***@localhost ~]$ uname -a<br>
Linux localhost.localdomain 3.13.11-100.fc19.x86_64 #1 SMP Wed Apr
23 20:10:57 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux<br>
<br>
[***@localhost ~]$ yum info libusbx<br>
Loaded plugins: auto-update-debuginfo, langpacks<br>
Installed Packages<br>
Name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : libusbx<br>
Arch&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : i686<br>
Version&nbsp;&nbsp;&nbsp;&nbsp; : 1.0.16<br>
Release&nbsp;&nbsp;&nbsp;&nbsp; : 3.fc19<br>
Size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 127 k<br>
Repo&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : installed<br>
Loading...