Quantcast
Channel: Instrument Control (GPIB, Serial, VISA, IVI) topics
Viewing all articles
Browse latest Browse all 5565

USBTMC: a continous 0xFF data result in INITIATE_ABORT_BULK_IN message

$
0
0

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.)


Viewing all articles
Browse latest Browse all 5565

Trending Articles