• Welcome to Forum.Deepsoftware.Com. Please login or sign up.
 

Does TnrUSB.ControlRequest function violate the USB specification?

Started by Zdenek Hlavica, September 04, 2020, 01:07:29 pm

Previous topic - Next topic

Zdenek Hlavica

Hello,

I would like to ask you for help with TnrUSB.ControlRequest function. In case I initiate transfer from device to host, it looks like a result of transfer is successful only if the host receives exactly all data which were requested, please see your code:

    Result := WinUsb_ControlTransfer(hWinUsb, packet, request.Data, request.Length, sz, nil);
    if result
      then result := sz = request.Length;

But USB specification says that data stage of control transfer can be variable in specific case, please see text from USB specification:

8.5.3.2 Variable-length Data Stage
A control pipe may have a variable-length data phase in which the host requests more data than is contained in the specified data structure.  When all of the data structure is returned to the host, the function should indicate that the Data stage is ended by returning a packet that is shorter than the MaxPacketSize for the pipe. If the data structure is an exact multiple of wMaxPacketSize for the pipe, the function will return a zero-length packet to indicate the end of the Data stage.


But, in case a device doesn't have enough amount of data to send to host and data stage is ended by short packet or by ZLP, it looks like the TnrUSB.ControlRequest function doesn't provide real transferred size of data and always ends with fail status.

I believe the TnrUSB.ControlRequest shoud always return real size of transferred data from device and in the case mentioned above it should ends as an success.

Or, have I missed something?

Thanks,
Zdenek

Roman Novgorodov

Hello

Thank you for your information.

It seems like you are right.
The SZ variable receives value of necessary space of memory, but SZ is declared locally and method returns false. And caller has no ways to understand reason of returned FALSE.

We will a bit think and find a way to implement this method more suitable way.

I hope we can release a new version in the next two-three days.

Roman Novgorodov
DeepSoftware llc
DeepSoftware llc - The professional components for Delphi/CBuilder/.NET. The high quality custom software development.
Forums.nrCommLib.Com - DeepSoftware Tech Support Forum.

Zdenek Hlavica

Hello Mr. Novgorodov,

thank you for a quick response. It would be great to find better way how to implement this method. I'm looking forward for a new revision of nrCommLib!

Thank you and Best Regards,
Zdenek

Zdenek Hlavica

Hello Mr. Novgorodov,

I've installed nrComm Lib 9.57 to check updated TnrUSB.ControlRequest function. But I'm afraid it doesn't work as you intended. I will try to explain.

You added new item "LengthResult:cardinal" into "TnrUsbRequest" record to keep size of transferred data. In "ControlRequest" function you wanted to fill the "LengthResult" item:

function TnrUSB.ControlRequest(request: TnrUsbRequest): boolean;
...
 request.LengthResult := 0;
 Result := apiUsb.ControlTransfer(request, request.LengthResult, nil);
...

But apparently the "request" is local variable in this case and filling the "request" structure does have only effect inside the "TnrUSB.ControlRequest" function. So an input "request" structure outside the function is not actually updated and user can see only random values in "LengthResult" item.

I understand you tried to make solution which ensures backward compatibility. Please consider to create second separated function, something like that:

function TnrUSB.ControlRequest2(request: TnrUsbRequest; var LengthResult:cardinal): boolean;
...
...

Thank you and Best Regards,
Zdenek

Zdenek Hlavica

Hello Mr. Novgorodov,

any comment or idea about the issue?

Thank you and Best Regards,
Zdenek

Roman Novgorodov

Hello

Thank you for the information.
We will release a new version the next week.

Roman Novgorodov
DeepSoftware llc - The professional components for Delphi/CBuilder/.NET. The high quality custom software development.
Forums.nrCommLib.Com - DeepSoftware Tech Support Forum.

Zdenek Hlavica

Hello Mr. Novgorodov,

thank you very much for fixing the issue. The nrComm Lib rev 9.59 finally works well.

Best Regards,
Zdenek