Bruno
I don't know whether you can see everything with Wireshark but there is certainly a STALL taking place in the uTasker binary (although I don't get the log sense when I connect to my Win 10 machine I can still simulate it). Comparing the simulation result and the recording that you made:
The host sends the log sense in line 943.
I don't know how to interpret the lines 944..949 but I suspect it is showing a stall taking place and the stall being unstalled (although the unstall takes pace on endpoint 0 and I don't know whether this is filtered out or not).
950 is the termination of the process where the device is reporting that the previous command failed (the very last 1 in the data packet is the result - CSW_STATUS_COMMAND_FAILED, which is 1). This is exactly what I see when simulating the case and it is normal behavior for an unsupported command. Therefore the answer is "reporting the failure of the last request" and not actually handling it in any specific way.
Looking at your case:
It looks like the additional traffic is related to the stall process but I don't know how to interpret the content with Wireshark, or whether Wireshark really sees all details. I notice that there is a SET_FEATURE request following it and I suspect that what you are seeing is in fact the USB hub communication which is commanding it to perform a bus reset due to the previous activity causing an unrecoverable error.
My careful conclusion would be that you do have a problem with stalling which doesn't cause the host to wait (and timeout) but immediately declare a serious error and command a reset [maybe we are seeing it make two or three retries at something in the process]. There is a possibility that the actual error is the unstall part (eg. it is trying to unstall but not the correct endpoint that actually stalled - this would be my first point of investigation in fact).
Since I don't know how reliable the Wireshark recordings are (USBpCap looks still be be in the experimental stage) I prefer to use dedicated USB analysers for my work (although I can't exclude that the details are in there if one knows how to interpret correctly).
I would have offered you to send me a binary that I can run on a FRDM-K22F board but the application USB socket has recently broken off mine so I will need to order a new one. If you can build the project for any other board with USB (eg. FRDM-K64F) I could quickly run it though.
Note that you can also verify the stall process by removing support of another typical command for experimental purposes.
Regards
Mark
P.S: If you do have problem solving this in SDK it is also possible to use uTasker USB in FreeRTOS 9.0 projects with further advantages that the project is no longer device dependent and can run on any Kinetis part without porting. I have used it in many industrial projects since 2008 (on Coldfires) and since 2011 on most Kinetis parts; it is proven to be bullet-proof and allows mixing composite devices with almost no effort.
P.P.S. I can also solve SDK problems if needed in emergencies but this would require a contact since it is quite difficult to understand all SDK's USB operating details and so not always as efficient.
Hey Mark,
thanks for the tips. In Wireshark, the addresses (if I understood correctly) are formed as BUS.DEVICE.ENDPOINT. That menas 1.3.* and 1.1.* are different devices and from the pictures, I'd say the board is enumerated with the address 1.1.*.
Wireshark indeed doesn't show much of the communication and I unfortunately don't have a Hardware USB Analyzer. I found, though, another tool that gave me better results: Microsoft Message Analyzer. I redid the experiments with this tools and got the following results:
My firmware
During enumeration, I get some problematic packages (6 packages). They show problems with Stall commands followed by endpoint halt command, but enumeration goes fine.
After enumeration, communication goes on as it was on the Wireshark experiments (several Bulk In and Bulk Out Transfers), until eventually I get the following error: Status Babble. This makes windows close the endpoint and open it with a different address (??) - I don't really understand that, but I do understand there is an error with the Status message.
Your Firmware (initial one, without FreeRTOS)
The same Stall problems during enumeration appear, but this time I can see 9 times the problem.
During execution, your application too get some other stall problems followed by endpoint halt, but I can't see any status babble problems.
I'll go further into this status babble problem, as it seems to be causing the problem (bus reset).
I attached the trace files.
Cheers,
Bruno
So, I actually manage to narrow the problem even more.
Using the demo application from the SDK 2.3, I get the same problem. The image below is using dev_composite_cdc_msc_freertos_frdmk82f with USB_DEVICE_CONFIG_USE_TASK set to 1, running on a FRDM-K82F board.
Every ~5min, the Status Babble is reported, the endpoint is closed and the Bus is Reset (one can see on the image above that every time the bus is reset, the host PC gives a new address to the device.
The exact same thing happened with the FRDM-K22F running the simpler demo from SDK 2.3 dev_msc_ramdisk_freertos_frdmk22f with USB_DEVICE_CONFIG_USE_TASK set to 0. The demo dev_msc_ramdisk_bm_frdm_frdmk22f presents the same problem.
Conclusion: this is a problem with the NXP's USB Stack and not my application.
To reproduce, just flash one of the MSD examples in a dev board and monitor the USB using Microsoft Message Analyzer. You'll see that the device will receive a new address after one or two minutes of the enumeration and then every 5 min.
I'll try to narrow down where, in the stack's code this problem is originated, but I expect a positioning of NXP on the matter.
Cheers,
Bruno
