I tried on an older Samsung Chromebook, updated to the latest OS. It looks like you're running in developer mode or something like that.

1. Could you confirm and describe what you're doing in terms of developer mode?
2. If dmesg is available, could you paste what's in the system log when you plug in the board? That will give us some clues about what the USB issues are. Thanks.
3. Did it work with an older version .uf2 on the Trellis? If so, which one?

I do see /dev/ttyACM0 with a Trinket M0 on my Chromebook, but not with 4.0.0-beta.2. I'm trying to use BeagleTerm. I can't connect, but that may be for other reasons.

The underlying USB implementation has changed, and so it appears that something has changed is causing the Chromebook not to recognize the USB CDC serial device.

I was able to see the system logs via file:///var/log/messages. I don't see any errors, and ttyACM0 is mentioned in the logs when I plug it in, but it's not visible to BeagleTerm. I don't want to wipe this chromebook to enable developer mode, so I may try some other way (like putting CloudReady on a laptop).

I also tried the latest build of CircuitPython and it's still not working. It's not specific to the Trellis.

I installed the latest version of CloudReady, which is Chromium OS, on an old netbook and did not have this issue, so I'm not sure what's going on. Tagging @hathach for reference, but this is going to be trickier to debug than I thought. I'll get some USB traces from my other Chromebook at some point.

So to answer your questions from before:

1. The only developer mode I thought I enabled was to turn on the linux BETA for chromebooks https://support.google.com/chromebook/answer/9145439?hl=en Other than that I don't remember ever turning on developer mode.
2. Looking at dmesg I dont see anything new added after plugging in and out. Link to before and after messages here: https://drive.google.com/open?id=188NloJ0XiLJDcyqcyPmNYEzbGWYvtZpx
3. I have tried this with the 4.0.0 0 and 4.0.0 2 beta builds and neither have worked.

I replicated the problem with a Trinket M0 and a circuit playground express.
The serial device and the CIRCUITPY drive never appeared. TRINKETBOOT did appear when I reset to the firmware upload mode.

The kernel logged errors after starting to enumerate the HID devices then disconnected the USB device. Which was then detected and the process started over.

I recompiled the same CP version with CIRCUITPY_USB_HID=0 and then the serial port and drive both appeared on the chromebook. I was able to use Beagle Term to get to the REPL.

• CP Version: 4.0.0-beta.2-199-g2eaa98ad7 on 2019-03-06
• ChromeOS version: 72.0.3626.117
• Kernel version: Linux localhost 3.18.0-18747-gdea8d908bd77 CTRL-D should reset board, but does nothing #1 SMP PREEMPT Mon Feb 18 22:32:03 PST 2019 x86_64 Intel(R) Celeron(R) CPU N3160 @ 1.60GHz GenuineIntel GNU/Linux
• USB 3.0 ports

I can pull the kernel logs off of the system if it would be useful.

It is definitely USB HID issue, I remembered that CPY doesn't support boot protocol for keyboard. Maybe chromeOS trying to switch protocol to boot mode, and doesn't receive correct response from CPY. Hard to tell for sure, but it is a possible cause. I haven't used chromebooks before, could It be run with virtual box to troubleshoot the issue, if yes, please tell me which version chromeOS I should download to begin with :D

As a fun thing, It does work 100% correctly with the same cable and device on my Windows 10 machine. Do you think If I removed the HID library from the device it would work on my chromebook?

It's not the HID library - the device shows up whether the library is there or not. I'm going to get some USB traces with a USB hardware logging device and see if something looks strange. It's also odd that it works OK with CloudReady - this is mysterious.

EDITED: After further testing it seems I got the kernel versions wrong.

I have more data but no solution.

I tested on a CentOS 7 system with a Redhat patched 3.10.0 kernel.
kernel version 3.10.0-229 3.10.0-693.21.1 (693.21.1 is Redhat's patch number) did not work.
kernel version 3.10.0-327 3.10.0-862 did work.
Redhat backports fixes from later upstream kernels into the RHEL/CentOS kernel. I'm guessing something is tickling a bug in the kernel.

Red Hat's changelog can be found here:
https://git.centos.org/blob/rpms!kernel.git/c7/SPECS!kernel.spec

I also did some more testing on the chromebook.

I changed tools/gen_usb_descriptor.py to remove the "GAMEPAD" device. With the GAMEPAD device descriptor removed the drive and serial port appeared on the chromebook. If I only included the GAMEPAD device it did not work.

Hopefully this helps narrow down where to look.

@hathach Here are two Beagle traces when plugging a Trinket M0 into my Samsung Chromebook. One is CircuitPython 3.1.2, which does appear as /dev/tty/ACM0. The other is CircuitPython 4.0.0-beta.4, which does not appear. The Chromebook is a Samsung XE303C12, running 32-bit Chrome OS, the latest version available for this: 72.0.3626.122.

circuitpython-4.0.0-beta.4-trinket-m0-samsung-chromebook-usb2.tdc.zip
circuitpython-3.1.2-trinket-m0-samsung-chromebook-usb2.tdc.zip

More data: If I look at the CPy startup with gdb (using a Metro M4), then I see it crash with a backtrace like this:

(gdb) bt
#0  0x00020276 in reset_into_safe_mode (reason=reason@entry=HARD_CRASH) at ../../supervisor/shared/safe_mode.c:81
#1  0x0001f570 in HardFault_Handler () at supervisor/port.c:290
#2  <signal handler called>
#3  memcpy (dst=dst@entry=0x20000dcc <_hidd_itf+12>, src=<optimized out>, n=n@entry=7)
    at ../../lib/libc/string0.c:62
#4  0x00025f2c in tud_hid_generic_get_report_cb (report_id=<optimized out>, report_type=<optimized out>, 
    buffer=0x20000dcc <_hidd_itf+12> "", reqlen=<optimized out>) at ../../shared-module/usb_hid/Device.c:72
#5  0x000254fc in hidd_control_request (rhport=<optimized out>, p_request=0x2002ff48)
    at ../../lib/tinyusb/src/class/hid/hid_device.c:441
#6  0x00024114 in process_control_request (p_request=0x2002ff48, rhport=0 '\000')
    at ../../lib/tinyusb/src/device/usbd.c:384
#7  tud_task () at ../../lib/tinyusb/src/device/usbd.c:257
#8  0x00025c0e in usb_background () at ../../supervisor/shared/usb/usb.c:78
#9  0x0002642e in run_background_tasks () at background.c:56
#10 0x0001f1b6 in run_code_py (safe_mode=safe_mode@entry=HARD_CRASH) at ../../main.c:244
#11 0x0001f410 in main () at ../../main.c:439

However, if I compile with -fno-inline (in an attempt to get ride of the <optimized out> stuff above), then sometimes it works, doesn't crash, and I see CIRCUITPY and /dev/ttyACM0. Ugh 🤕 . I thought it was always true with -fno-inline for a while, but now it's crashing even with that.

@dhalbert thanks for the trace file, I saw control endpoint didn't response after request to get input report from HID with report ID = 0x05. Can you help me to dumb HID report on your pc as follow command.

sudo usbhid-dump -d 0x239a -i3 | grep -v : | xxd -r -p | hidrd-convert -o spec

You may need to install hidrd, on linux it is simply sudo apt install hidrd

this is not important, but the interface number of your descriptor is a bit odd, the sequence isn't in order and is as follow.

• 0,1 for cdc
• 2 for msc
• 4,5 for MIDI
• 3 for HID

Shouldn't them be in order !!??

@hathach The traces are from the chromebook. I'm not sure I can run usbhid-dump or equivalent on it -- maybe if I switch to developer mode -- (have to wipe it to do that) . Or did you want it from just any Linux host?

You can dump while attaching to your main pc. I just want to know which report ID host is trying ro get

Btw, did the issue happen with other mcu such as m4 or nrf5x ??

@hathach Interestingly, seems to be SAMD-related. M0 and M4 boards don't show up as /dev/ttyACM0, but nrf52480 boards (Feather and PCA10059) are showing up.

@dhalbert hmm, I guess it could be setup packet handling code specifically with samd port. Give me a bit of time, I will check and try to come up with a patch for you to test again.

@hathach here is the hidrd output from a Metro M4:
cpy-hidrd.txt

As noted above, if we remove the GAMEPAD, /dev/ttyACM0 shows up.

One thing I am thinking of in the long run is making the keyboard be a boot device, in an unshared endpoint. A few people have asked for that so they can use a board as a boot keyboard.

Thanks @dhalbert, though I think it is most likely usb port issue now, since the stack handles it just fine with nrf port.

I did an hidrd report with the Feather nRF52480, and it's identical.

For boot keyboard, tinyusb should be able to handle that now. Though there may be a bit of gotcach, can you open an issue for boot device and assign me there. I will do a PR for that

Here is a Beagle trace of the Feather nRF52840, which is reporting a descriptor that should be identical non-working trinket M0 from the 4.0.0 trace above.
circuitpython-4.0.0-beta.5-feather-nrf52840-samsung-chromebook-usb2.tdc.zip

Though there may be a bit of gotcach, can you open an issue for boot device and assign me there. I will do a PR for that

Hi, do you mean a tinyusb issue or a CircuitPython issue? No problem for us doing it for CPy.

@dhalbert most likely tinyusb port issue ☺☺ but could be both, need to give it a few try to be sure :)

Also tested Metro M0 with 4.0.0-beta.5 on same Samsung Chromebook as above. Didn't work either, so it doesn't appear to be a crystalled-vs-crystalless difference.

I just tested a build of #1721
It worked fine on Centos 7 and my chromebook.

phew, finally this is fixed 👍 👍