USB Descriptor incorrectly reports crow as supporting AT messages

[trentgill]

On linux, this means the OS will send AT messages to crow whenever it is connected. These messages cause evaluation errors in the crow REPL and will trash the first command called. These messages take around 7 seconds to complete, which is frustratingly long when trying to debug a script.

This can be reduced by buffering REPL commands on the host side (using readline or similar), and prepending the \e escape character to strings in the first few seconds (thus aborting previous input).

Fixing this requires looking into the specifics of the USB driver configuration. I've spent a good 45mins searching for the value that sets this, but to no avail. Perhaps it's in the STM usbd library itself?

[trentgill]

@tehn Spent another hour on this just now. I went through the full USB descriptor in the stm lib and everything seems setup correctly. I tried changing all the parameters that would theoretically make the host not send the AT commands, but they kept happening regardless.

At this point I'm going to retag this to the 2.0 milestone when we hopefully have a larger team of devs that might be able to shed some light on what's happening.

In the meantime we can work around this by using a readline based 'druid' thing, and prepend messages with a single \e char to clear any data in the buffer. In the worst case, Lua will reject the input string and the user will need to type it again. This is only a problem until the first message after the first 7seconds from boot.

[simonvanderveldt]

@trentgill on which distro are you experiencing this? There's nothing that does this by default in the kernel, so I'd assume it's something like ModemManager that's doing this.

[trentgill]

i'm on Ubuntu 16.04.5 LTS i think it also happened on windows10, but not on osx 10.11 or 10.12

[simonvanderveldt]

So if/when you're running ModemManager it does indeed trigger on device detection (via udev)

May 31 22:05:54 [ModemManager] <info>  [device /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6/2-1.6.1/2-1.6.1.3] creating modem with plugin 'Generic' and '1' ports_
May 31 22:05:54 [ModemManager] <warn>  Could not grab port (tty/ttyACM0): 'Cannot add port 'tty/ttyACM0', unhandled serial type'_
May 31 22:05:54 [ModemManager] <warn>  Couldn't create modem for device '/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6/2-1.6.1/2-1.6.1.3': Failed to find primary AT port_

(Not sure why I'm getting that warning, could be because I disabled most of ModemManager during compilation)

Anyway, this ModemManager integration can be disabled via a udev rule:

$ cat /etc/udev/rules.d/98-monome-crow.rules 
# Monome crow
# Disable ModemManager
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="5740", ENV{ID_MM_DEVICE_IGNORE}="1"

This will need a reload of the rules to enable it sudo udevadm control --reload-rules.

Once this is done ModemManager will no longer interact with the device. Could you check if this solves the issue for you?

[trentgill]

Just a quick note to say I finally tried the above (ie. adding the udev rule & reloading rules) and it solves the problem! Wishing I'd spent the 10 minutes to test it back in May!!

[simonvanderveldt]

That's good to hear, then we have at least a solution/workaround.

Is there no way to configure crow's USB client in the firmware in such a way that it doesn't present itself as a modem? (I don't know if there's another mode that would allow interactive send/receive that isn't the modem mode)

[trentgill]

FYI, need to kill ModemManager before running the command to update the rules for this to work. Strange that it doesn't work after a system restart?

[trentgill]

Another update. on Ubuntu 18, setting the rules.d file didn't fix the ModemManager issue. Instead, I've just resorted to disabling modem manager altogether as I don't have any devices that need it: sudo systemctl disable ModemManager.service

[simonvanderveldt]

Another update. on Ubuntu 18, setting the rules.d file didn't fix the ModemManager issue.

That's very strange, AFAIK nothing has changed with regards to how the modemmanager specific ignore needs to be defined. Maybe you need to do a restart after making the change? Or maybe 18.04 (assuming that's the version) is too old/has older versions of udev and modemmanager that don't support this?

[simonvanderveldt]

@trentgill Is this still happening on 18.04 (assuming it's that version)? Are you using plain Ubuntu or some other spin of it? I can check why it's not happening. I don't think we can fix this ourselves because we have no way of delivering udev rules to our users, so the only thing we can do is document it.

Why don't we change the device type that the STM is configured to be to a normal serial port instead?

[trentgill]

Why don't we change the device that the STM is configured to be type to a normal serial port instead?

This is the thing I've tried to do numerous times & never succeeded at. I don't know if it's a bug in the stm32 usb driver, or a poorly documented API, or I just haven't figured the magical bits.

I believe it should be settings in https://github.com/monome/crow/blob/main/usbd/usbd_desc.c, either in the group of defines at L:55 or the USBD_DeviceDesc array at L:94.

I'd be thrilled if someone else took on the details of figuring this out.

(yes, it's 18.04 stock ubuntu)

[a773music]

Just wanted to chime in and say that the udev rules fixed the issue for me on debian/buster

[trentgill]

i was doing some digging in the CDC driver re: the new grid firmware, and discovered these settings that might have some impact next time someone has a spare moment looking for a quick project: https://github.com/trentgill/STM32CubeF7_USB/blob/5b966f90bfbe0a4a0f5580fe7a715c44b212d0d2/STM32_USB_Device_Library/Class/CDC/Src/usbd_cdc.c#L279

[tehn]

good find. now i need to remember how to test this...