Closed DeviousFusion closed 3 years ago
How strange. I wonder if it might be worth experimenting with the USB_MSD_PWR_OFF_TIME
option? https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md
USB is not under the control of the rpi-eeprom after Linux has started because PCIe is reset first. The OP suggests that the device fails to enumerate with the newer VLI firmware 137ad vs 138a1, that's more likely to get attention as a raspberrypi/firmware bug report.
that's more likely to get attention as a raspberrypi/firmware bug report.
@DeviousFusion See https://github.com/raspberrypi/firmware/issues/
@DeviousFusion to pre-empt a debug question, it would be worth checking whether connecting via a hub or powered hub resolves the situation.
@lurch and @timg236 Thank you for your comment and suggestions. I have not tried playing with USB_MSD_PWR_OFF_TIME
option since it seemed to deal with the bootloader only and not the post boot OS.
As suggested, I used a powered hub and everything works fine and the device gets enumerated with 138a1. I'm not sure what's exactly going on, but based on my understanding, since the device has external power it doesn't reset when the Pi is booting up.
Do you think my theory is right and this has something to do with the bootloader enumerating USB devices for boot and the 3D printer freezing up during that stage? Also regardless of my theory, do you guys still prefer that I open a new issue at raspberrypi/firmware?
Thanks
Yes, it does look like the Teensyduino is getting into a "confused" state and not appearing on the USB bus. Maybe you could try setting USB_MSD_EXCLUDE_VID_PID
to 16c00483
? :shrug:
Is your Pi booting from SD card or USB? What's your BOOT_ORDER
set to?
(I don't actually know much about the bootloader or USB, I'm only trying to offer helpful suggestions :slightly_smiling_face: )
Thanks for the help @lurch . I'm booting off a 16GB SD Card. No USB bootable devices connected. As for the BOOT_ORDER
, I haven't touched it. So its safe to assume that its the default 0xf41
Since I'm booting off SD, and the default boot order checks for SD first, it shouldn't be scanning for USB devices. So I'm not sure if the MSD
options will help, but I'll give them a try tomorrow.
Thanks again.
If the USB hub is working then I'd stick with that.
During a reset on Pi4B the USB port power will briefly be reset. Some devices don't like this and the default is to increase it to a couple of seconds to look like a disconnect / reconnect. USB_MSD_PWR_OFF_TIME lets you configure this to be zero or longer.
Unfortunately using a USB hub is not feasible. We have 10 3D printers and will be expanding to more.
I tried with USB_MSD_PWR_OFF_TIME
and USB_MSD_EXCLUDE_VID_PID
but that doesn't help. Here is the config and lsusb:
pi@polyprinter-8:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@polyprinter-8:~ $ sudo rpi-eeprom-config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
USB_MSD_PWR_OFF_TIME=5000 //tried with 0 as well
USB_MSD_EXCLUDE_VID_PID=16c00483
Based on what I read in the documentation at https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md , the USB_MSD_*
should only work if USB boot is detected. Since I am using SD card, the above options won't work. Also should the device be even resetting when using SD card boot? I feel that there should be a way to disable the reset USB_BOOT is not enabled/available.
Are there any other options/configs instead of adding powered hubs to each printer?
I think I remember @timg236 saying that the (brief) USB reset is unavoidable on later revisions of Raspberry Pi 4B. (Tim: In hindsight, is this the boards without a separate VLI EEPROM? :thinking: )
@DeviousFusion Perhaps it's worth opening the firmware bug report that was suggested earlier, in case there's a way of resetting the USB controller from "the Linux side" rather than "the EEPROM bootloader" side? :wink: :man_shrugging:
The firmware doesn't get involved with USB and USB_MSD_EXCLUDE_VID_PID won't do anything useful because the device would have had to have enumerated first.
The failure is that the device is not connecting and is therefore invisible software. That's why a powered hub will be the most reliable option.
You could the latest bootloader release via 'raspi-config' 'Advanced Options' (pieeprom-2021-03-18.bin). The reset behaviour is frozen around 2020-09-03 behaviour so you'll probably see the same behaviour.
I will close this issue here and will open a new one in https://github.com/raspberrypi/firmware Thanks for the help though.
Hey everyone! We have 10 3D printers at a FabLab and recently decided to upgrade our Raspberry Pis from Pi2 to the newer Pi4. Unfortunately we are running into an issue where the 3D printers are not getting detected by the Raspberry Pi unless we manually reset the board. This happens only on the newer firmware versions. Also I can confirm that this is not a hardware issue, since it happens with all 3D printers and Pis. I have attached all the information below including dmesg from both firmware cases.
Mandatory information
Describe the bug 3D printer fails to get detected at boot. The only way to get the device to get detected is manually pressing the RST button on device after the OS has booted. This only happens on VL805 FW later than 000138a1.
To Reproduce Steps to reproduce the behavior: Boot with 3D printer connected
Expected behaviour 3D printer should be detected automatically at any time
Bootloader version and configuration Default bootloader config
SD card boot (please complete the following information):
Network boot (please complete the following information): N/A
USB boot (please complete the following information): N/A
Additional context
As stated above the problem was not present when using older firmware (000137ad). Additional info:
When using new firmware (Jan 2021)
Output of rpi-eeprom-update:
lsusb:
When using older firmware (April 2020) Check lsusb where the device gets detected without user intervention
DMESG outputs: dmesg_137ad.txt dmesg_138a1.txt
I'm willing to share additional information as required.