Hi:
We are developing a Data Acquisition Instrument which expected to support USBTMC(subclass
488 not included), so that it can communicate with Labview easily.
While during the firmware implemention, we meet the problem described below:
(We want to send int32 type data to the host,eg: 1 (0x00000001 in binary) and -1 (0xFFFFFFFF in binary))
After receiving the REQUEST_DEV_DEP_MSG_IN command message, the device respond with a DEV_DEP_MSG_IN message as the USBTMC Specification required.
When the data is 1 (0x00 0x00 0x00 0x01 in data payload), the transport finished
properly. But when we send -1 (0xFF 0xFF 0xFF 0xFF in data payload), the host abort the Bulk-IN transfer with a INITIATE_ABORT_BULK_OUT command message through the endpoint 0.
After testing, we found that when there is a continous 0xFF (e.g 0xFFFF ) in the data
payload, the host will abort the Bulk-IN transfer with a INITIATE_ABORT_BULK_IN command
message.
We did not find any requirement about the data(in the data payload) in the USB & USBTMC
Specification, so we are confused about this. Is there any requrements about the data in
the data payload?
and what does the following mean in the USBTMC Specification:
4.2.1.4 INITIATE_ABORT_BULK_IN
A Host may use the INITIATE_ABORT_BULK_IN request to abort a Bulk-IN transfer and restore
Bulk-IN synchronization. A Host should only send an INITIATE_ABORT_BULK_IN request when
resynchronization is necessary (Note: This is USBTMC Bulk-IN transfer re-synchronization,
not the USB defined DATA0/DATA1 toggle synchronization.)
