From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

USBTMC: host continuously sending bulk OUT packets

Solved!
Go to solution

Hi,

We are developing firmware for a new TMC device. Device is successfully enumerated as IVI class [Refer: 1_WinDeviceMgr.png]

The firmware is at a very basic level at this stage with Control EP handling all the standard requests (Get Capabilities is not yet in place); bulk out end point is ready to data.

 

Currently I am stuck with an issue that, host driver  is indefintelty sending BULK OUT data packates [Refer: 2_BeagleTrace.png] - the same behaviour is observed when using both Win and Linux hosts!

 

I am not sure to understand this behaviour.USBTMC class specs [USBTMC_1_00.pdf and USBTMC_usb488_subclass_1_00.pdf]  looks straightforward.

 

Can you please clarify:

 

1 - Windows is able to detect this device - but NI MAX is not able to identify this (I ve followed NI forum link as well - http://digital.ni.com/public.nsf/allkb/BE81A3BE80E415D2862579DB006B131A)

2 - Why there is a continuous EP1 - BULK OUT data from host?

3 - Connected beagle lists this new device (7) on BusIdx:7; there are no bulkout data on EP1 !, but not sure from where the "Unknown Device (8): (BusIdx:2) EP1 OUT data is coming from? probably due to this, our device library is confused and failing to understand the data!

4 - My understanding is, beagle snoop should enumerate only bus index 8, but not sure to why there are '8 bus indexes' listed!?

 

 

Kindly throw some light if you have any clues on these -  Beagle capture [3_beagle_trace.tdc] is also attached for your reference.

 

 

Thanks for your support.

 

regards,

Srinivas

Download All
0 Kudos
Message 1 of 4
(5,079 Views)

According to the USB TMC standard:

 

The control endpoint is required by the USB 2.0 specification. The Bulk-OUT endpoint is required and is used to provide a high performance, guaranteed delivery data path from the Host to the device.  The Host must use the Bulk-OUT endpoint to send USBTMC command messages to the device, and the device must process the USBTMC command messages in the order they are received. The Host must also use the Bulk-OUT endpoint to set up all transfers on the Bulk-IN endpoint.   The Bulk-IN endpoint is required and is used to provide a high performance, guaranteed delivery data path from the device to the Host.  The Host must use the Bulk-IN endpoint to receive USBTMC response messages from the device.

 

If you don't provide BULK out and in, you're apparently not TMC conform.

0 Kudos
Message 2 of 4
(5,050 Views)

Hi Intaris,

Thanks for your reply.

 

Yes, indeed. I have both the bulk out and bulk in end points in the device firmware. What is surpirising is, host continuously sends Bulk OUT messages (with message data as 0x 72 00 00 00) as in the captures that I shared previously!

This is not clear as the message id is not correct as per the Spec, and the BULK OUT data content does not seem to be valid at all 😞

 

I have not yet implemented GET_DEVICE_CAPABILITIES - could this be the cause of this behavior?

Any feedback/clues are greatly appreciated.

 

Regards,

Sriniv

 

 

 

0 Kudos
Message 3 of 4
(5,036 Views)
Solution
Accepted by sriniv

Hi,

An update on the below issue:

- Still there is network traffic (with message data as 0x 72 00 00 00), but using an option to discard this messages, the data end points (bulk OUT and bulk IN) are ready to operate for the TMC functionality!

- Linux USBTMC driver requests for GET_CAPABILITIES message, and hence this needs to be supported at least on the device code, apart from the data exchange between the bulk end points

- NI MAX and NI labVIEW can recognize the device only of the Serial number field > 0

 

By catering to the above adjustments, our device firmware started to work good.

 

Thanks for your feedback and support.

 

Regards,

Sriniv

0 Kudos
Message 4 of 4
(4,927 Views)