Commentary on our 'ajayxfer.cpp' and 'ajayecho.cpp' demos

We did not (yet) find an authoritative technical specification for the 
behavior of the 'NET20DC' Hi-Speed USB 2.0 Debug Cable, as produced by 
Ajays Technology; hence our program-code is based on 'trial-and-error'
experiments and may need to be modified in light of future experience,
for example with PC hardware platforms that differ from ours. 

The 'USB2 Debug Device: A Functional Specification' document (from the
Intel website), dated March 2003, predates the NET20DC implementation;
it anticipates the need for some departures from the USB 2.0 standard,
due for example to the 8-byte limitation on packet-size imposed by the
EHCI controller's register design, the handling of the NYET status for
OUT endpoints, the absence of the usual 'default' device state, etc.  

One unanticipated 'operational difference' when using this Debug Cable
relates to our use of the DATA0 or DATA1 Packet-IDs in the stages of a
control transfer, such as 'Get_Descriptor' and 'Set_Feature': we found
that we could use either DATA0 or DATA1 with equal success in the DATA 
phase of the control transfer, but that we could NOT use DATA1 for the
STATUS phase of our 'Get_Descriptor' control transfer, contrary to the
customary USB device behavior.   

Another surprise we encountered concerned the number of bytes returned
by the NET20DC device in response to a 'Get_Debug_Descriptor' control-
transfer: the debug descriptor's documented length is 4-bytes, and the
device reports that 4-bytes were transferred, while in fact we observe
that 6-bytes are returned.  

We also encountered some curious timing anomalies with regard to 'NAK'
responses from the OUT endpoint, which -- without a Programmer's Guide
from the manufacturer -- will need some further experiments to clarify
this device's behavior if optimum transfer-speed is to be achieved.    

ALLAN CRUSE
01 FEB 2010
revised on:
11 FEB 1010

Addendum on 17 FEB 2010: We encountered a further anomaly today, made
visible during the 'Set_Feature' transaction (to set the Debug Mode):
when we initialized the Debug Port's DATABUF registers with a pattern
of all 1's just prior to the DATA phase of this control transfer, the
NET20DC device was seen to return two zero-bytes despite a 'count' of
zero bytes transferred in the Debug Port's CNTL_STS register.  Taking
a fresh look at the screen-output produced by previous demo-programs.
namely 'ajayinit', 'ajayxfer', and 'ajayecho', we now see this effect 
already was present, but it went unnoticed without the pattern of 1's
being written to the DATABUF registers prior to the DATA phase of the
control-transfer transaction.  --ABC