RPi wont boot RatOS when 2 USB boards connected
Hi Everyone.
Last night I put RatOS on SD card and booted the RPi. During the setup I connected (via usb cable) the BTT Octopus MAX EZ board and flashed, then connected the EBB42 (via USB cable) and flashed. All seemed to be going well and was able to do the printer.cfg config. Once done I shutdown and went to bed.
Today I tried switching on the system again and I first switched on the BTT boards (the MCU's have a separate 24-volt PSU and the RPI its own 5-volt PSU), then switched on the RPi only to notice that the RPi power light comes on but green light never flashes and thus not booting.
Removed both USB cables... RPi boots,
Add 1 MCU.... RPi boots,
Add 2nd MCU.... no boot,
remove first MCU... RPi boots.
So not specific to the USB MCU as it will boot with either plugged in, but not with both.
Tried another RPi-specific PSU and nothing... Connected to the first PSU and bumped voltage to 5.2V... Still nothing...
Has anyone seen this before? Any Advise?
Edit:
Just to add, while both USB cables are connected and the power is off on the MCU's, RPi will boot and I can power on the MCU's afterwards and everything is working.
30 Replies
Yes @Helge Keck experienced something similar on one of his pi's. I think we boiled it down to a component on the Pi that might've been substituted for another during the chip shortage. It seems like the pi's bootloader gets confused and tries to boot off of one of the USB's instead of the sd card.
I don't remember if we ever found another work around besides powering/connecting the MCU's after booting the pi.
I have a few suggestions worth trying:
1) Try using a USB stick instead of an SD card for RatOS.
2) Try a usb hub
3) Try rearranging which ports you're using. Ie. only USB 2, only USB 3.0 (the blue ones) or one of each
It might be worth to try updating the pi firmware / bootloader as well.
yes, this sounds like the same issue. i experience it with USB or SD card boot
You never found a fix did you?
my solution is a relais that powers the secondary board on
Yeah
Seems like he already sort of has a setup to facilitate that
i think only real solution atm is to cut the USB power connector to one of the boards
i once hoped enable pin feature would work, but it doesnt
The octopus max EZ should have a USB power jumper that should've been removed
already got gnd from usb
So at least that's not connected to power
But not all the toolboards have a USB power jumper
I don't think there's one on the EBB42
in my case there is no difference if i use 5V jumper or not
there is one
But it works if you tape off the power pins on the cable?
(or cut them for that matter)
dont understand?
i think only real solution atm is to cut the USB power connector to one of the boardsWas wondering about this comment
ahh, i said it bc if you would cut the USB power connector you cpould easily use a enable pin like feature to power it dealyed on
but usb is not powering the boards anyway?
i tried it but the issue is USB already is GND connected and its always oin
you need to switch the 24V pin
Got it
Yeah so the point is to only power the boards after the Pi has booted
yes
its anoying, but this works at elast
its ok if you power it on 5 seconds after turning on th epi, thats already enough
maybe there is even a better hardware solution to this than switching a pin
Well his Pi is on it's own 5V supply, so that could control a Sonoff for the rest of the printer for example
yep
but this still bothers me after this time, i know this issue can be fixed with software, i know it bc it happens one time here
Yeah, i wonder if there's a way to force the pi to not attempt USB booting
Googled. There isn't.
It's supposed to try SD first before attempting USB, but obviously that's not the case with these odd pi's.
Once the USB boot bit has been set in the ROM it cannot be undone..
i wonder if it is anyway a good idea to first power on the pi and then power on all the rest of the printer, like some seconds delayed
or turniong the rest on if the pi boots successfully
in a automated way of course
Hi Gentlemen, was out last night for a business dinner. Just caught up on all the comments.
I guess booting Pi first is the workable solution, feels like a bandage solution.
Agree that this seems like a "Boot Order" problem from all the other Pi threads I have read.
Going to try 2 things today:
1. USB hub (I have already tried moving to other ports on the Pi with no luck.... even a combo of using USB2 and USB3 to separate MCU's on their own bus)
2. I purchased a new RPi 4 (4GB) last week. Exactly the same model as I have installed. Just going to do a quick swap to see what happens.
So, I did 3 different test's and the third one was the most surprising (will post in 3 different comments.
This is original connections with the back USB being the BTT Octopus MAX EZ (although, as mentioned, no difference no matter what combination of ports used.... 1XUSB3 & 1XUBS2 or 2XUSB2 or 2XUSB3)
Tried my new RPi 4 (4GB). Same model.....Well, not so same if you look at the components on the board. - This works ALL the time
The only very obvious chip/component difference is close to the USB C power port where there are 4 different components compared to the new RPi. This seems to be related to the Power for the RPi
Next test was with a USB hub attached and MCU's BOTH plugged into the hub. This Worked!! - Did not expect this.....but did multiple power cycles and had no issues.
I then also plugged the BTT Octopus MAX EZ into the RPi and then the EBB42 into the hub (hub plugged into same port as the EBB42 was originally).... Shocked, but this also worked.....
So just adding a hub in line with EBB42 made all the difference.... Not sure why
Yeah pretty much as expected. Super annoying, but fortunately it seems to only affect one or two batches of Pi's produced in that period.
Just another question while on 2 PSU's... On the DC side, should the Negative of the 24V PSU and the Negative of the 5V PSU be wired together for "common negative reference" balancing?
Yes, that's always a good idea
It doesn't do much in your case though, but it doesn't hurt 🙂