WIndows 10 CIRCUITPY enumeration issues

[TheKitty]

I've had some issues with my CP devices lately.

1) I have a desktop USB hub, using that at times I can't get a CircuitPython device to enumerate to Windows 10 2) I have had a good number of issues after upgrading from Mu 1.01 to beta to 1.0.2 getting the serial window to open properly. I cleaned out the unused COM ports in Windows Device Manager as a first try, still issues maybe related to #1.

Or it could be #2 is due to #1.

Issue logged per request of @dhalbert

[debrouxl]

We've also just noticed something which looks like an USB enumeration issue on Windows 10, so I thought I'd post in this issue, rather than create a new one.

@TheKitty could you test whether a CircuitPython build based on commit 5b0c1c8df9b205221b50c588abf4106dced0ca1c works for you ?

Background: today, when testing my attempt to rebase the top two commits from https://github.com/debrouxl/circuitpython/commits/master (my modified version targeting the TI-Python Adapter ~ Trinket M0), @critor noticed that after flashing the board with my firmware, the USB connection disappears: neither MSD, nor CDC are visible anymore from the computer. His Windows 10 computer states ~"This device cannot start (code 10)".

There's no such issue with the official firmware, or the previous build of my firmware based on 5478610e591f404baeb60d01d0997754ba4734cb - the USB connection capability is restored by switching back to either of these.

I attempted to find the bad commit manually (since I'm applying patches on top of the circuitpython commits), then I entered the good/bad information produced by critor into git bisect: both methods pinpoint 9d43a25d6e9336646aa8cf62cad6ae53f232d324 . Here's the bisection log:

git bisect start
# good: [5cc52fb7b7a21f4f8c8b410b1c7d9f5f7d106565] Merge pull request #1727 from tannewt/remove_lwip
git bisect good 5cc52fb7b7a21f4f8c8b410b1c7d9f5f7d106565
# bad: [f8473f4a3917f7816fccd1be2a67041a7dfce5ef] Merge pull request #1788 from tannewt/pinyin
git bisect bad f8473f4a3917f7816fccd1be2a67041a7dfce5ef
# bad: [cf3f3e510caf33fb5354caf62755ff80c37d1cdf] Merge pull request #1774 from tannewt/pybadge_revd
git bisect bad cf3f3e510caf33fb5354caf62755ff80c37d1cdf
# bad: [129e7255995b258c71d06227ac265c2746eac3af] Merge branch 'master' into master
git bisect bad 129e7255995b258c71d06227ac265c2746eac3af
# bad: [df058c971fe37b2f7f3214eea952b4a5c2b8d442] Merge pull request #1751 from makermelissa/ssd1331
git bisect bad df058c971fe37b2f7f3214eea952b4a5c2b8d442
# good: [19278e0284f0339576b7fe9e0bdd6ad312da208a] Merge pull request #1736 from nickzoic/circuitpython-nickzoic-1046-nrf-rtc-2
git bisect good 19278e0284f0339576b7fe9e0bdd6ad312da208a
# good: [b5bc8b3fc2b0b97d1d444f1139e3d89f1b63f7ac] Merge pull request #1745 from dhalbert/rotaryio-typo-eic-refactor
git bisect good b5bc8b3fc2b0b97d1d444f1139e3d89f1b63f7ac
# bad: [5f057d183a13f9ae6e286f94be0de291d47a5e1d] move pybadge to faster subjob
git bisect bad 5f057d183a13f9ae6e286f94be0de291d47a5e1d
# good: [5b0c1c8df9b205221b50c588abf4106dced0ca1c] Merge pull request #1743 from tannewt/fs_testing
git bisect good 5b0c1c8df9b205221b50c588abf4106dced0ca1c
# bad: [9d43a25d6e9336646aa8cf62cad6ae53f232d324] update tinyusb to fix disconnect/suspend issue with #1681
git bisect bad 9d43a25d6e9336646aa8cf62cad6ae53f232d324
# first bad commit: [9d43a25d6e9336646aa8cf62cad6ae53f232d324] update tinyusb to fix disconnect/suspend issue with #1681

EDIT: critor says that the USB communication against a build produced from https://github.com/debrouxl/circuitpython/commits/master_with_tinyusb_revert works :)

[siddacious]

@dhalbert, could this be the same issue as #1749 ?

[debrouxl]

FWIW, for me, the first bad commit post-dates 4.0.0-beta.6 :)

[dhalbert]

@siddacious - Possibly... This may be a timing issue.

@hathach Take a look at the report above and let us know if you have any thoughts.

[tannewt]

@debrouxl @TheKitty What boards have you tried this with? Beta 7 on a CPX worked for me. 70dd6167c07c5d72ae9b803aa25ccb8f1905ec35 on a Metro M4 worked as well.

What models are the computers? (I'm Windows Version 10.0.17134 Build 17134 on a Ryzen 5.)

@debrouxl Where does the "This device cannot start (code 10)". message appear?

[hathach]

@tannewt "This device cannot start (code 10)" is probably in the device manager of windows

[dhalbert]

@debrouxl @TheKitty @siddacious I'm trying to track this down, so I thought I'd ask if you if you could give an inventory of the software installed on your machine. These utilities list installed software, drivers, and security software, respectively. They'll produce a simple HTML report (look under View), or save a list as a text file (select all the items and then choose File->Save.

If you're willing to run these and post the results here, I'd be grateful. If you want to prune the lists for privacy, that's fine.

The downloads are listed at the bottom of each page. You probably want the 64-bit version when there's a choice.

http://www.nirsoft.net/utils/installed_packages_view.html http://www.nirsoft.net/utils/installed_drivers_list.html http://www.nirsoft.net/utils/security_software_view.html

If you know of a similar utility, great. Belarc Advisor is not as thorough and does not include drivers.

[dhalbert]

Another thing that would be helpful is a USB trace. This requires either some hardware (Beagle, usually), or else setting up Wireshark and USBPCap to capture the USB events. If you are familiar with this or have such a device, let us know.

@siddacious Are you seeing the same errors as above, or is #1749 different? For instance, if you try before and after the commit @debrouxl has noted, do you see success on a build before that commit? I can make some test builds for you if it would save you time.

[siddacious]

@dhalbert I have seen the "things disappear after flashing" behavior previously with a different board but that wasn't what I've been seeing with my feather m0. I believe it was with my metro m4 when I flashed it with beta 7 to get a backtrace for the i2c issue I reported.

I have the above reports but they're too large to inline here. I can give them to you on discord.

I will try before and after the commit mentioned. I don't have a beagle but I suppose I could get one if you thought it would be worthwhile. In the meanwhile I can try and get wireshark going.

[siddacious]

@dhalbert was looking through the reports and found this which you had previously mentioned

==================================================
Driver Name       : HpSAMD
Display Name      : 
Description       : 
Startup Type      : Manual
Driver Type       : Kernel
Error Control     : Normal
Group             : SCSI Miniport
Filename          : C:\WINDOWS\system32\drivers\HpSAMD.sys
Driver File Type  : System Driver
File Created Time : 9/15/2018 12:28:17 AM
File Modified Time: 9/15/2018 12:28:17 AM
File Size         : 64,312
File Description  : Smart Array SAS/SATA Controller Media Driver
File Version      : 8.0.4.0 Build 1 Media Driver (x86-64) (PART_L3.130128-0938)
File Company      : Hewlett-Packard Company
File Product Name : Smart Array SAS/SATA Controller Media Driver
Base Memory Address: 
End Address       : 
Memory Size       : 
Load Count        : 0

[siddacious]

 5b0c1c8 : fails
5478610: : fails

It's very possible that I'm not seeing the same thing as @debrouxl

[dhalbert]

@siddacious Thanks for all the info. Don't spend time on the Wireshark stuff for now. Let's see what the new Feather M0 shows.

[dhalbert]

You can zip up all the reports in the reports and then include the .zip file here.

[siddacious]

win10_m0.zip

[siddacious]

@dhalbert I had already done a capture by the time I saw your comment, so I included captures of a failure and success in the above zip.

[debrouxl]

@critor 's tests used a M0-class TI-Python Adapter platform, which was featured several times on the Adafruit blog, against Windows 10 1803 17134.706. AFAWCT, unsurprisingly, the TI-Python Adapter and various M0-based platforms have excellent compatibility: several Adafruit platforms and the Arduino Zero can run TI's firmware verbatim, and the TI-Python Adapter can run at least my improved build of CircuitPython featuring more math functions. critor is familiar with USBPcap, he's used it multiple times to capture graphing calculator <-> computer communication dumps for several models I didn't, and don't, have. He'll run the programs you requested above later, I suppose :)

Because the device <-> host communication issue is very reliable for him (if the tinyusb merge is part of circuitpython, then the device can never be detected by the computer, otherwise it can always be detected), I had started making the bisection inside tinyusb code, but he wasn't able to test my first build yet.

[dhalbert]

@debrouxl I just want to understand clearly what's failing. Tell me if this is correct: You have seen this problem with regular (not just custom) CircuitPython builds at commit 9d43a25 and later. When a board (including several Adafruit boards) is running a CircuitPython build at or later than that commit, then it does not enumerate on your Windows 10 machine.

1. Is the above correct?
2. Does it have to be running a particular boot.py and main.py/code.py, or is it just the CircuitPython build itself that causes the problem?
3. Have you and @critor tried other Windows machines, including ones updated to Windows 10 1809?

Yes, if you can get a USBPCap trace of the failure, that would be extremely helpful. Don't use a hub; a direct connection is better. Thanks very much.

[dhalbert]

@TheKitty Does the problem happen if you do not use the hub? Does it happen with beta.7, with and without the hub?

[dhalbert]

@siddacious HpSAMD.sys is included in all Windows installs. The SAMD is Storage Array Media Driver, unrelated to SAMD chips (which you probably know already). I don't remember mentioning that driver, but I think it may be a red herring.

[siddacious]

@dhalbert OK I just saw "Smart Array" and SAS and though it might be related to the SMART issues you noticed earlier this week.

[critor]

@debrouxl @TheKitty What boards have you tried this with?

For me, only Trinket M0.

What models are the computers? (I'm Windows Version 10.0.17134 Build 17134 on a Ryzen 5.)

Confirmed the issue on two Asus laptops running Windows 10 family build 17134.

[dhalbert]

@critor Could you post the .uf2 you are using, if it is not a CircuitPython build, and point to a GitHub repo commit that it was built from? Are you building off the latest master? You can zip it up and attach it here.

What CPU chip is used in the Asus laptops: is it an AMD, or Intel, and what model?

[critor]

I'm not building the firmware myself, I've just been testing binaries provided by @debrouxl on my Trinket M0. So I'll let him clarify.

[debrouxl]

Today's tests show that he can't reproduce the problem with pristine master (sorry, I should have checked earlier). However, he can reproduce at will with small changes in the USB ares on top of current adafruit/circuitpython master HEAD, which I've pushed at https://github.com/debrouxl/circuitpython/tree/trinketm0_usb_comm_broken_after_tinyusb_change . It's just a matter of disabling and not building USB HID + USB MIDI support, and poof, USB communication capability between @critor 's computer and real Adafruit Trinket M0 is gone. Before merging by 9d43a25d6e9336646aa8cf62cad6ae53f232d324 a set of 41 tinyusb commits, disabling USB HID + USB MIDI support used to work: I've consistently used that for a couple months in my modified CircuitPython builds targeting the TI-Python Adapter. This change is critical for both compatibility with the official TI-Python Adapter firmware, and most of all, for saving space to provide a better feature set for school teaching purposes than the official TI-Python Adapter firmware...

So it looks like I should have created a separate issue, sorry for polluting this one with what turns out to be probably unrelated.

circuitpython_trinketm0_master_nousbhidmidi_20190420_0920_debrouxl.zip

[dhalbert]

@debrouxl You have to remove the HID and MIDI devices from the USB descriptor as well. I did that: here's a diff from the branch you linked to above. My changes are the two ####### to comment out those devices.

I haven't tested this other than to see that CIRCUITPY now appears again (on Linux).

diff --git a/tools/gen_usb_descriptor.py b/tools/gen_usb_descriptor.py
index 10bbf5066..ae824b207 100644
--- a/tools/gen_usb_descriptor.py
+++ b/tools/gen_usb_descriptor.py
@@ -276,14 +276,14 @@ descriptor_list.extend(cdc_interfaces)
 descriptor_list.extend(msc_interfaces)
 # Only add the control interface because other audio interfaces are managed by it to ensure the
 # correct ordering.
-descriptor_list.append(audio_control_interface)
+#######descriptor_list.append(audio_control_interface)
 # Put the CDC IAD just before the CDC interfaces.
 # There appears to be a bug in the Windows composite USB driver that requests the
 # HID report descriptor with the wrong interface number if the HID interface is not given
 # first. However, it still fetches the descriptor anyway. We could reorder the interfaces but
 # the Windows 7 Adafruit_usbser.inf file thinks CDC is at Interface 0, so we'll leave it
 # there for backwards compatibility.
-descriptor_list.extend(hid_interfaces)
+#######descriptor_list.extend(hid_interfaces)

 configuration = standard.ConfigurationDescriptor(
     description="Composite configuration",

The USB stuff is relatively brittle right now. We are going to make it more configurable, but not in 4.0. Have you also disabled a bunch of other stuff to make room, like CIRCUITPY_PULSEIO, etc.?

[debrouxl]

Thanks for pointing tools/gen_usb_descriptor.py, I had missed it :) I somehow had to patch it further for critor's computer to detect the Trinket M0 running a build from the current https://github.com/debrouxl/circuitpython/tree/master , but it's all fixed now, great.

I understand very well that the 4.0 release is nearing and that you don't want to delay it by spending time making USB more configurable for the benefit of infrequent people targeting an oddball I/O-less platform, and wanting to cram as much math functionality as possible into 184 KB of Flash, despite the usage of DPFP numbers, which are not even CircuitPython's main focus. I'd probably do the same if I were in your shoes ;)

I have disabled miscellaneous stuff to save space, in a more or less hacky way. The two (merged) PRs I sent were a result of that work. Upstream changes made since early February have reduced the number of hacks I needed to get the code to build; maybe some of the hunks of the second commit in my branch pinpoint changes which could make sense upstream, but I've already unwittingly hijacked this issue for too long...

[dhalbert]

@debrouxl I am impressed you got doubles and associated code into a small build!

[dhalbert]

No recent reports of the origianl problem. Closing for now.