Objective Development Forums

This is not making sense to me. I have a descriptor that uses a set, get, and 5 outputs. This descriptor is the FFB example by Microsoft. I can show all relevant code if needed but it will dramatically complete things. I rather step my way in to this mystery question at a time. So here is what I currently see.

gett -> gets cough in usbFunctionSetup GOOD.
set -> gets cough in usbFunctionSetup GOOD.
output t -> gets cough in 1usbFunctionWrite HUH.
output 2-> gets cough in 1usbFunctionWrite HUH.
output 2-> gets cough in 1usbFunctionWrite HUH.
output 3-> gets cough in 1usbFunctionWrite HUH.
output 4-> gets cough in 1usbFunctionWrite HUH.
output 5-> gets cough in 1usbFunctionWrite HUH.

Now, to my understating you use the return USB_NO_MSG from a get or a set to run the usb function write or read. This is only needed if data exceeds 8 bytes and you can not return the payload up front. So I'm very confused how the outputs go right to 1usbFunctionWrite. I would except them to first hit usbFunctionSetup (set report). Now the output reports are bulk, maybe this is why, if so where is this explained?


Now for the part that really complicates matters. If my first get returns the size 5 (as it should based on the descriptor) none of the outputs are caught in the usbFunctionWrite . I actually have to return USB_NO_MSG from my get report. This makes absolutely no sense because outs are not gets at all, they should be sets....

If neither of these questions have answers then my confusion is sane. I'll add the code and see if its a programing issue and not an understanding issue. If what I typed above does make sense, what am I missing?

to make things worse
Windows sends output reports as interrupt-out data if possible and expects input reports on the interrupt-in endpoint. Only feature reports are always communicated as control transfers on endpoint 0. It is therefore advisable to use feature reports for your data. We will only cover feature reports here.

Isn't that a nice how do you do...

Ok I finally found this

Using Interrupt- and Bulk-Out endpoints

Interrupt- and Bulk-Out endpoints are used to send stream type data to the device. When the host sends a chunk of data on the endpoint, the function usbFunctionWriteOut() is called. If you use more than one interrupt- or bulk-out endpoint, the endpoint number is passed in the global variable usbRxToken. You must define USB_CFG_IMPLEMENT_FN_WRITEOUT to 1 in usbconfig.h when you use this feature.


Some how the driver is getting confused but this explains thing for me. It is not working but I just learned about it. Seems the usbFunctionWriteOut is never getting called, I did set
#define USB_CFG_IMPLEMENT_FN_WRITEOUT 1
could there be an issue with having usbFunctionWriteOut and usbFunctionWrite both defined and being used?

my end points are
7, /* sizeof(usbDescrEndpoint) */
USBDESCR_ENDPOINT, /* descriptor type = endpoint */
0x81, // bulk IN endpoint number 1
0x03, /* attrib: Interrupt endpoint */
8, 0, /* maximum packet size */
0x08, /* in ms*/

//the output.

7, // sizeof(usbDescrEndpoint)
5, // descriptor type = endpoint
0x01, // out endpoint number 2
0x03, // attrib: Interrupt endpoint
8, 0, // maximum packet size
0x08, // in ms

Looks like we may have another bug here.

if(usbRxToken < 0x10){ /* endpoint number in usbRxToken */
change it to this:
if(usbRxToken == USBPID_OUT){ /* endpoint number in usbRxToken*/


so this works but breaks control sets where no_msg is used. After more headaches I noticed that the return is causing the issues so I now have this.

#if USB_CFG_IMPLEMENT_FN_WRITEOUT
if(usbRxToken == USBPID_OUT){ /* OUT to endpoint != 0: endpoint number in usbRxToken */
usbFunctionWriteOut(data, len);
//return;
}

this provides to be a perfect solution.

Did you make a clean build after you defined USB_CFG_IMPLEMENT_FN_WRITEOUT? I have done a code review and think that it should work. In asmcommon.inc there are the lines:



`token` is finally stored to `usbRxToken`. It is only set to the endpoint number if asmcommon.inc has been compiled with USB_CFG_IMPLEMENT_FN_WRITEOUT defined to 1.

I did as you suggested but still have the same issue? What can I look at to further this investigation.

Interesting... It's possible that refactoring (code size improvements, but fixes) broke something. I know that it did work when it was implemented.

The most reliable way to find out what's going on is analytic debugging. I would change the C code to make a trigger pulse on an I/O line when `usbRxToken` < 0x10 is seen and trigger a storage scope with that pulse. Then I' would print the value to a serial output and view the data on the scope. You may start without a scope, just print the value in `usbRxToken` to a serial line. The project already has a debug log function which can be enabled. Only if you suspect a misinterpretation of the message, it's necessary to look at the data.

I currently don't have the time for in-depth debugging, sorry.

Turns out I must have had a corrupt, partial or old version of the driver. I had no reason to suspect that but changing a define blew up the code. So after I re downloaded to fix that I figure I better come back to this bug. Sure enough that also fixes this issue.