Closed renedavoh closed 3 months ago
Thanks for trying the latest BSP, and for indicating that this issue happens on Windows. I'm interpreting "doesn't recognize the COM port" as "the USB serial logger doesn't work on Windows, because the COM port never appears." Let me know if this isn't accurate. (Just want to make sure this isn't a matter of COM ports changing numbers; this is expected.)
teensy4-bsp
0.4 uses imxrt-log
for its USB serial logger. imxrt-log
was developed against a non-Windows host OS. My first guess is that there's a USB device behavior within or beneath imxrt-log
that Windows doesn't like.
I can't troubleshoot this by myself without a Windows host, so I'll need the community's help. If you have the time and equipment, I have two tests that might help us isolate the issue.
Build the imxrt-usbd
serial example like this:
git clone git@github.com:imxrt-rs/imxrt-usbd.git
cd imxrt-usbd/examples/teensy4
git checkout d5a40a1
cargo objcopy --release --bin=serial -- -O ihex serial.hex
Upload serial.hex
to your Teensy 4.1. At this point, you should observe a blinking LED.
Try connecting to the COM port, and enter characters. If the COM port enumerates, you should be able to submit characters and receive the same characters back.
Does this work? This evaluates a simple loopback USB serial device without imxrt-log
.
Build the imxrt-hal
logging example (without RTIC) like this:
git clone git@github.com:imxrt-rs/imxrt-hal.git
cd imxrt-hal
git checkout a15ffda
cargo objcopy --release --example=hal_logging --features=board/teensy4 --target=thumbv7em-none-eabihf -- -O ihex hal_logging.hex
Upload hal_logging.hex
to your Teensy 4.1. At this point, you should observe a blinking LED.
Try connecting to the COM port. If the COM port enumerates, you should see an occasional log message with an incrementing counter.
Any luck here? This still uses imxrt-log
, but it uses it in a slightly different way than what teensy4-bsp
does.
Same for both examples on Windows:
I compared "lsusb -v" output for this examples and old version (which uses Teensyduino library):
Changing this hardcoded value in the usb_device crate made both examples work on Windows:
The differing bcdUSB
values is a helpful observation. From my understanding, when Windows (or any USB host) observes bcdUSB > 2.00
, it can query for binary device object store (BOS) descriptors. By changing that hard-coded value from 0x10
to 0x00
, Windows shouldn't query for BOS descriptors. This seems similar to rust-embedded-community/usb-device#35.
I don't want to rule out an issue in our own device configuration. Although there's an extra HID class in the mix, https://github.com/rust-embedded-community/usb-device/issues/102 talks about approaches to troubleshoot a CDC device against Windows. It might be easy to explore those suggestions in the imxrt-usbd
serial example.
I tried to capture the traffic with wireshark/USBPcap to compare bcdUSB versions. USBPcap does not capture any packagesfrom the unpatched (bcdUSB 2.10) version.
@renedavoh Hi, as per this discussion: https://github.com/mciantyre/teensy4-rs/discussions/132#discussioncomment-5204129, could you check if this command also solves your issue (without changes to bcdUSB)?
IMXRT_LOG_USB_BULK_MPS=512 cargo build [...]
👍 With IMXRT_LOG_USB_BULK_MPS=512
the hello-world example works on Windows.
Following the recommendations in this thread, imxrt-log 0.1.2 increases the default MPS to 512.
Describe the bug When compiling/updloading the teensy4-rs-template to Teensy 4.1 Windows doesn't recognize the COM port (since Update to 0.4 of teensy4-bsp).
To Reproduce
Upload with Teensy Loader
Additional context Older template using teensy4-bsp v0.3 works as expected.