Re: [pyusb-users] Reverse Engineering an evaluation board

[Shailendra P. <bei...@gm...>]

On Sat, Feb 24, 2018 at 8:50 AM, Xiaofan Chen <xia...@gm...> wrote:

> On Sat, Dec 23, 2017 at 3:43 PM, Shailendra Paliwal
> <bei...@gm...> wrote:
> > Hello,
> >
> > I'm trying to communicate with an Analog Devices evaluation board
> (SDP-H1).
> > AD has a windows software that initializes the board and can be used to
> read
> > the data coming from the USB connection with the board.
> >
> > I have been trying to write something in pyusb that can do the same and
> work
> > with my Raspberry Pi. So far, I have figured out how to initialize the
> > board. I need help in understanding the protocol used in fetching data
> from
> > it.
> >
> > Device Descriptor: http://shailendra.me/USB.html
>
> Page not available.
>
Thanks, I have managed to make a USB driver that works nicely so far.
Coincidentally I took down that page *only* a few hours ago of your email!
Here's a copy of the page from an older commit, link
<https://htmlpreview.github.io/?https://raw.githubusercontent.com/vcidst/vcidst.github.io/fd11064e66e702046c0b29a09eb8c4f728292d02/USB.html>


>
> > Here is the PCAP file of the USB trace:
> > https://github.com/vcidst/vcidst.github.io/blob/master/
> sdph1-data_clean.pcap
> > (you can use wireshark to open pcap files)
>
This link has been removed too.


> >
> > I've read a lot of write-ups of people reverse engineering USB protocols
> > which mostly include looking at the control transfers. However, this
> device
> > only has two bulk endpoints and all the communication is done with bulk
> > transfers.
> >
> > Quick facts about the PCAP file:
> > * Replaying packets 1-108 initialize the board.
> > * At packet 109 (use filter frame.time_relative >= 40), In the windows
> > software I chose sample size 1048576 and press Continuous Capture button.
> > * Packets 109 to 119 prepare the capture from SDP-H1.
> > * From packet 120, 6 packets of similar structure are sent/received again
> > and again.
> > * After that, I see 6 packets of different structure at
> (frame.time_relative
> >>= 41.059593)
> > * Packets after (frame.time_relative >=41.073968) are of different
> structure
> > again until the end.
> > * Towards the end, I stop the capture from the windows software thus the
> > last few packets should be stop packets .
> >
> > My questions now are,
> > 1. Is this device following any standard USB protocol format that I am
> not
> > familiar with?
>
> Most likely it uses vendor specific protocols not falling into standard
> USB device class definitions.
>
> > 2. I'm currently replaying the packets to initialize the device, is
> there a
> > better way to do this?
>
> If you do not know the protocol, this seems to be the only way.
>
> > 3. (a basic question that I still don't understand) in USB Communication,
> > after I have sent Bulk Write request. Do I need to send a bulk read
> request
> > if I need to read some data? Can the program just not read whatever the
> > device sends without me sending the device anything?
>
> No. USB does not work that way. The device does not automatically send
> data to the host without host initiate the communication.
>
> > 4. The data packets here are huge and I was wondering if I need to send
> the
> > entire packets whenever sending a bulk write request. Is there a way I
> can
> > figure out what is essential information in the packet and what is not?
>
> If you do not know the protocol, I do not think you have a way to know
> what is essential and what is not. You have to look into the huge data
> and then try to understand. All in all the efforts required may be huge.
>
> > (I have read the Bulk Transfer section from USB in a Nutshell but still
> > didn't understand why it has to be this way unlike say, RS232
> communication
> > where the device can keep on sending data in continuous mode)
>
> USB is much more complicated than serial communication.
>
> On the other hand, there is probably an easier way out without using
> the SDP-H1 if your interests are to connect your Raspberry Pi to a
> paticular
> daughter board. Quite some of them using SPI protocol. The schematics
> and documentations of the daughter boards are available.
>

I considered that option but the daughter board made the results available
on a single low voltage differential signaling self clocked interface. The
data rate required is as much as ~20 MBPS so I worked directly with their
evaluation kit first.

Thanks for your inputs. I think I will write a blog post soon detailing my
process and the tools I made use of.


>
>
>
> --
> Xiaofan
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> pyusb-users mailing list
> pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>