Closed paunstefan closed 1 year ago
Prints and gdb are very tricky with USB as it's a very time sensitive protocol. So you can't take the usual debugging approach.
I would recommend setting up defmt and a very fast debug adapter (something usb 2.0 hispeed, like https://www.nxp.com/design/microcontrollers-developer-resources/mcu-link-debug-probe:MCU-LINK).
From my experience, this is often a bug in the USB hal driver (or a message not being handled correctly).
You may also want to use wireshark to see if there's something wrong going on as well (ideally, you'd have something like this https://www.totalphase.com/products/beagle-usb12/, but they are pricey).
Which MCU are you using?
Sorry, I forgot to mention it, it's a Raspberry Pi Pico.
I managed to fix after looking through Wireshark captures. The problem was that the PC was sending a report for the Num Lock LED, which I wasn't reading on the device, if I read it and just discard it everything works well.
I'm not sure this issue is related to this crate, it can be deleted if it's considered off-topic.
I made a firmware for a macro keypad using this crate, initially everything worked fine, tested it on PCs with Fedora 36 Gnome, Ubuntu 22.04 and Raspberry Pi OS. The problem appeared on Fedora KDE, where after the device sends a few reports to the PC, the main thread seems to freeze, while the interrupt handler continues trigger. It only happens while logged in to the desktop environment, works fine in the login screen or on a non-graphical TTY.
Possibly relevant code from the project:
Tried to put defmt prints and it doesn't seem to freeze in the same place everytime. GDB doesn't really help because breakpoints also block the interrupt handling.
Any ideas on what could cause it or how could I continue to debug it?