8000 USB fails to enumerate when CIRCUITPY_USB_HID = 0 · Issue #2840 · adafruit/circuitpython · GitHub
[go: up one dir, main page]
Skip to content

USB fails to enumerate when CIRCUITPY_USB_HID = 0 #2840

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
xobs opened this issue May 1, 2020 · 17 comments
Closed

USB fails to enumerate when CIRCUITPY_USB_HID = 0 #2840

xobs opened this issue May 1, 2020 · 17 comments

Comments

@xobs
Copy link
xobs commented May 1, 2020

Beginning with b3b6a64, USB no longer enumerates when using Simmel, based on the nRF52833. Reverting that commit fixes USB.

After doing a mass_erase of the internal flash and loading the SD and bootloader, I load firmware.uf2 via USB. The device resets itself, attempts enumeration, and a short time later triggers an assert:

(gdb) c
Continuing.
nrf52.cpu: external reset detected
nrf52.cpu: external reset detected

Program received signal SIGTRAP, Trace/breakpoint trap.
process_set_config (cfg_num=1 '\001', rhport=0 '\000') at ../../lib/tinyusb/src/device/usbd.c:744
744         TU_ASSERT( drv_id < USBD_CLASS_DRIVER_COUNT && drv_len >= sizeof(tusb_desc_interface_t) );
(gdb)
@dhalbert
Copy link
Collaborator
dhalbert commented May 1, 2020

Just to double check, did you do a git submodule update after pulling the latest? I'd guess so, but I just want to make sure you got the very recent TinyUSB fix that allowed us to proceed with that PR.

I tested this on an nRF52840 on Ubuntu 20.04.

Tagging @hathach, who may want to know more.

@xobs
Copy link
Author
xobs commented May 1, 2020

Yes, the tinyusb module is at a74a823b0a140667a4e4e80fa2678870faba2bd0 committed 30/04 at midnight, although the only updates I see to nrf module in tinyusb in the past month have to do with renaming the irq handler to dcd_init_handler.

@dhalbert
Copy link
Collaborator
dhalbert commented May 1, 2020

On what kind of host is this, and do you see the same thing on a different OS?

@xobs
Copy link
Author
xobs commented May 1, 2020

That's a very good question. This is on a Windows machine.

It's difficult to move the board between machines, because the power cables are a little fragile. However, I also see errors when I plug it into a Raspberry Pi:

[539218.392350] usb 1-1.4: new full-speed USB device number 5 using dwc_otg
[539218.526172] usb 1-1.4: New USB device found, idVendor=1209, idProduct=c051, bcdDevice= 1.00
[539218.526187] usb 1-1.4: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[539218.526197] usb 1-1.4: Product: Simmel
[539218.526206] usb 1-1.4: Manufacturer: Betrusted
[539218.526216] usb 1-1.4: SerialNumber: 4E84A16AFEBF1E06
[539218.527055] usb 1-1.4: can't set config #1, error -32

Windows is much pickier when it comes to USB errors, so I could definitely see it issuing a reset when it failed to set the config, which is probably causing hathach/tinyusb#179

So it does seem like I'm getting USB errors on Linux as well as on Windows, they're just more catastrophic on Windows.

@dhalbert
Copy link
Collaborator
dhalbert commented May 1, 2020

I tried this with a Circuit Playground Bluefruit (nRF52840) on a Dell Intel laptop and a desktop, both running Windows 10, and they seem to be enumerating fine. Both MSC and CDC are working.

I then also tried on an RPi, and the logs don't show the errors you have above.

I'm not sure why it would be peculiar to the '833.

@xobs
Copy link
Author
xobs commented May 1, 2020

Me neither. Maybe it has something to do with v7.0.1 of the SR? I'm still unclear how that factors into it.

@xobs
Copy link
Author
xobs commented May 1, 2020

I just tried on a NRF52833-DK EVK board, and I see the same thing. If you have one of these, I can give you instructions on how to reproduce the issue.

This is using the Simmel bootloader (https://github.com/simmel-project/bootloader) which shrinks the bootloader partition to 16 kB and removes bluetooth/serial from the bootloader.

@dhalbert
Copy link
Collaborator
dhalbert commented May 1, 2020 •
edited
Loading

Do you have an nRF52840 board you can try with the same CircuitPython commit? It would have 6.1.1, unless you went to some effort to upgrade the build. I guess you could try rolling the '833 SD back to 6.1.1, since it appeared to work. I agree that I don't see why that should make a difference.

I successfully tried with a Feather nRF52840 on Windows too, because the CPB has only a 32MHz crystal. The Feather has both 32kHz and 32MHz, which is more typical.

I don't have an '833 dev board but I'll order one. I think @hathach might have one.

@xobs
Copy link
Author
xobs commented May 1, 2020

@tannewt said he had one, which is why he said I should create a PR for Simmel.

I won't have access to an NRF52840 (specifically a PCA10059) for a few days.

@hathach
Copy link
Member
hathach commented May 2, 2020

I have an 833 DK, but I don't see why it could run on 840 but 833. @xobs could you try to flash our stock bootloader on your 833 (best to be DK) with SD 6.1.1 to see if that would works. Since we don't enable SD, it wouldn't be an issue for testing USB with it.

Also it is helpful if you could provide bus capture along with tinyusb log as well by changing CFG_TUSB_DEBUG to 2 and retarget using tu_printf. It is a bit manual now.

@dhalbert do we have any printf debug log via RTT SWD now, I can submit an RTT to make getting log from tinyusb easier for future troubleshooting hathach/tinyusb#367

@xobs
Copy link
Author
xobs commented May 2, 2020

I created a PR to circuitpython to add the PCA10100 (aka NRF52833-DK). It uses v6.1.0 You can build it with:

make BOARD=pca10100 V=1 SOFTDEV_VERSION=6.1.0

It also exhibits the same issue.

@xobs
Copy link
Author
xobs commented May 2, 2020

PR is at #2844

@xobs
Copy link
Author
xobs commented May 4, 2020

This is the output I get from RTT:

00> Adafruit CircuitPython 5.3.0-128-ge3c6d0f-dirty on 2020-05-04; PCA10100 nRF52833 Dongle with nRF52833
00> USBD init
00> 
00> CDC init
00> MSC init
00> MIDI init
00> code.py output:
00> USBD Bus Reset
00> Hello World!
00> USBD Bus Reset
00> USBD Setup Received 80 06 00 01 00 00 40 00 
00> 
00>   Get Descriptor Device
00> 
00>   Queue EP 80 with 18 bytes
00> USBD Xfer Complete on EP 80 with 18 bytes
00>   Queue EP 00 with zlp Status
00> USBD Xfer Complete on EP 00 with 0 bytes
00> USBD Bus Reset
00> USBD Setup Received 80 06 00 01 00 00 12 00 
00> 
00>   Get Descriptor Device
00> 
00>   Queue EP 80 with 18 bytes
00> USBD Xfer Complete on EP 80 with 18 bytes
00>   Queue EP 00 with zlp Status
00> USBD Xfer Complete on EP 00 with 0 bytes
00> USBD Setup Received 80 06 00 02 00 00 FF 00 
00> 
00>   Get Descriptor Configuration[0]
00>   Queue EP 80 with 64 bytes
00> USBD Xfer Complete on EP 80 with 64 bytes
00>   Queue EP 80 with 64 bytes
00> USBD Xfer Complete on EP 80 with 64 bytes
00>   Queue EP 80 with 64 bytes
00> USBD Xfer Complete on EP 80 with 64 bytes
00>   Queue EP 80 with 26 bytes
00> USBD Xfer Complete on EP 80 with 26 bytes
00>   Queue EP 00 with zlp Status
00> USBD Xfer Complete on EP 00 with 0 bytes
00> USBD Setup Received 80 06 01 03 09 04 FF 00 
00> 
00>   Get Descriptor String[1]
00>   Queue EP 80 with 34 bytes
00> USBD Xfer Complete on EP 80 with 34 bytes
00>   Queue EP 00 with zlp Status
00> USBD Xfer Complete on EP 00 with 0 bytes
00> USBD Setup Received 80 06 00 03 00 00 FF 00 
00> 
00>   Get Descriptor String[0]
00>   Queue EP 80 with 4 bytes
00> USBD Xfer Complete on EP 80 with 4 bytes
00>   Queue EP 00 with zlp Status
00> USBD Xfer Complete on EP 00 with 0 bytes
00> USBD Setup Received 80 06 03 03 09 04 FF 00 
00> 
00>   Get Descriptor String[3]
00>   Queue EP 80 with 18 bytes
00> USBD Xfer Complete on EP 80 with 1800 
00>   Open EP 03 with Size = 64
00>   Queue EP 03 with 31 bytes ... OK
00> 
00>   MSC opened
00> process_set_config 744: assert failed

And a screenshot of the USB log:

image

It trips the assert fairly quickly, the final SETUP error is due to the assert being triggered which prevents the system from responding.

@dhalbert
Copy link
Collaborator
dhalbert commented May 4, 2020

If you could upload the datacenter packet log as well, that would be helpful to @hathach. Thanks!

I have an nRF52833 DK board arriving in a day or two, and will try to reproduce the problem.

@xobs
Copy link
Author
xobs commented May 4, 2020

nrf52833-dk-failure.zip

@xobs
Copy link
Author
xobs commented May 4, 2020

I'm beginning to think it's not hardware related, but rather to the fact that, in order to save space, I have CIRCUITPY_USB_HID = 0. I still see the HID descriptors in the config descriptor that gets sent out.

I think the nRF52833 is a red herring. Setting CIRCUITPY_USB_HID = 1 fixes the issue.

I'll update the title of this bug.

@xobs xobs changed the title USB fails to enumerate on nRF52833 with WFI patch USB fails to enumerate when CIRCUITPY_USB_HID = 0 May 4, 2020
@tannewt
Copy link
Member
tannewt commented May 4, 2020

Closing this in favor of #2850 now that we understand the issue.

@tannewt tannewt closed this as completed May 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@tannewt @xobs @hathach @dhalbert
0