RE: Blue screen on startup
This BSOD is a nuisance but likely low on the developer fix list. Developers figure most people will be standing in front of the printer at power-up, so they can just hit the reset button anyway. For me (at least) the belt tensioning wizard was a much better use of developer time.
I agree that it's mostly a nuisance -- except for those of us who use remote-controlled power outlets. While I would always prefer to take a direct look at the printer before I start a print, the ability to e.g. start pre-heating the chamber without heading down into the basement seems quite useful. Well, one can always keep power-cycling until the printer comes alive...
But it is also a really bad first impression when the printer starts with a blue screen. Ranks #3 in "worst possible greetings", right after exploding in the user's face or screaming at them... 😉 So if Prusa want to convey the "serious & reliable" image, they better fix this.
RE:
Well, based on the number of posts from new users for this, it does hurt the image. For those of us who've lived through the earlier days of the Core One, we've had enough exploding and screaming experience. Maybe more on the user side vs the printer side of things 🙂
I use a remote-controlled power outlet as well, but for 2.5 months it was re-purposed elsewhere in the house. Zero difference in how often the blue screen occurs.
I half figured my remote-controlled outlet was aggravating the issue but does not appear to be the case.
RE: Blue screen on startup
random thought, without checking schematics: Oscillator settling can be an issue. During startup you get clock cycles alright but they may be out of spec, causing downstream logic to hiccup.
RE: Blue screen on startup
random thought, without checking schematics: Oscillator settling can be an issue. During startup you get clock cycles alright but they may be out of spec, causing downstream logic to hiccup.
Might be... It seems this issue should not be overly difficult for Prusa to track down. They must know what they changed for bootloader 2.5. We don't, since as far as I'm aware it is not open source.
RE: Blue screen on startup
Interesting thought on the oscillator but generally not. Integrated oscillators settle within spec in a handful of cycles. PLLs a little longer (1-2us). They're not super-dependent on voltage. They are current referenced. Current references are silicon bandgap related and which themselves are super-stable.
Because the crash leads to a blue screen, it's fairly certain that enough initialization in the boot loader has occurred to setup basic hardware resources and configure the MCU watchdog timer. So, it happens many thousands of instructions after reset. Something fubars later on and the watchdog times out. Code vectors to the routine that dumps the basic message to the screen. Since a lot of other resources haven't been initialized, no crash dump. All you get is "I crashed but I don't know why".
RE: Blue screen on startup
I was wondering about the open source on the boot loader. Not surprised if it wasn't open source.
re: not overly difficult to track down ... the xBuddy board has a serial debug port on J21 for the MCU. Fair to say a debugger pod lives on the bench/desk of every developer. 100% a priority call to push a fix to the back burner. Bootloaders are kind of risky to mess with anyway. They could potentially find a fix but without thorough testing, you could wind up with bricks in the field.
They may know the root cause but have postponed the fix. Hard to tell.
RE:
PLLs a little longer (1-2us).
We're looking at a failing case, so let's assume a non-optimum situation. Example: ESP32 factory code uses 500 µs in some places, that's already half a millisecond, easily outpaced by impatient code. "Hundreds of microseconds" would seem typical for a PLL. And, depending how it's configured (possibly sub-optimally - we're looking for a bug, after all) this can vary quite a bit.
Even a plain crystal or MEMS resonator can be surprising because its Q factor is so ridiculously high. "Q" is energy stored in the resonator over energy dissipated per cycle. That means we need to pump the energy loss of many, many cycles into the material before it's in steady-state, and that takes time through loose coupling.
The consequences can be quite unintuitive if downstream digital runs into setup-/hold time violations, metastability etc.
RE: Blue screen on startup
Hold is frequency independent. Hopefully internal to the MCU, they have metastability sorted out. This is an STMicro MCU so give those folks some credit :). Generally, PLLs are output gated with lock to prevent exposing downstream logic to setup problems. They can overshoot pretty badly while locking. Valid concern as you pointed out on the specifics of an oscillator as it has no true reference and Q can vary. But from what I've seen, they don't tend be weird as PLLs.
Re: PLL startup time, for this MCU, it's 300us worst case. Had the pleasure of dealing with PLLs with lock times on the order a few of us. Perhaps application specific. I should have just looked it up in the datasheet, it was in front of my nose.
Since the issue cropped up in a specific bootloader version, it's unintentionally abusing something in the hardware no matter what.
RE: Blue screen on startup
I also have this problem from time to time.
My Core One is directly wired to a smart plug for switching it on and off from remote. Could this probably also cause an power/boot problem?
Bluescreen during booting of the Core One+.
RE: Blue screen on startup
Same here. My Core 1 + came assembled from Prusa. It sits in my Hobby Room in our house that has a very good HVAC system. The ambient temperature is very stable. Yet, about three times a week, the machine fails to boot. I turn it "off" and then back "on" and it then boots just fine.
I have no idea why it would give me the B.S.O.D. (Blue Screen Of Death), and then a quick reboot fixes it. Very curious.
I've had the same problem. Happens on cold start, works fine on restart. Printer is inside the house, so ambient temperature is not an issue. Hopefully it is just a bootloader bug and not a hardware issue.
RE: Blue screen on startup
There has been a JIRA assigned to it since August so not sure what the hold-up is. Of course I'm speculating but maybe they can't reproduce it?
RE: Blue screen on startup
I was having a similar blue-screen-on-powerup issue after I made an rpi mount for my C1. My first iterations used the cover for the wifi module as an attachment and laid the rpi against the back of the left power supply. The issue was traceable to having the rpi powered when the C1 was powering up and modifying my mount to move farther from wifi module solved it.
Looking for an RF noise source in the area of the wifi board might be fruitful.
RE: Blue screen on startup
I also have this problem from time to time.
My Core One is directly wired to a smart plug for switching it on and off from remote. Could this probably also cause an power/boot problem?
I used a smart switch for a while as well for a remote and I thought the same thing. It's been 3 months since I stopped using it. The boot problem is still there.
There has been a JIRA assigned to it since August so not sure what the hold-up is. Of course I'm speculating but maybe they can't reproduce it?
Very possible. Even without reproducing it, the speed at which it comes up (less than a couple of seconds) and the "Unable to show details" could be a clue to the rough location in the startup sequence. My hope is that it just goes away on the next release as code gets shuffled around a bit.
I was having a similar blue-screen-on-powerup issue after I made an rpi mount for my C1. My first iterations used the cover for the wifi module as an attachment and laid the rpi against the back of the left power supply. The issue was traceable to having the rpi powered when the C1 was powering up and modifying my mount to move farther from wifi module solved it.
Looking for an RF noise source in the area of the wifi board might be fruitful.
Good info. My C1 has always been in the same location and about 10' (3m) away from a mesh node. The C1 rear is on the far side of the printer from the node so in theory it has some shielding from the case. I could power-off the node and see if it helps but currently, the C1 bluescreens 2-3 times a month at startup. Maybe not enough to justify the node loss. The reset button is always a reliable fix and can be pressed before I leave the room. For people relying on remote power control, it's more of a pain than not. One picks their battles.
RE: Blue screen on startup
I don't understand why Prusa appear to have such a hard time fixing it. They must know what was changed in boot loader 2.5, and there can't be that many suspects for this problem.
RE: Blue screen on startup
Could be a priority thing vs difficulty.
Since it's strongly points to the bootloader 2.5 and the reset button reliably avoids the blue screen, I struggle to believe that the start of the bootloader execution differs between the two flavors of startup because of what I noted from the schematics. Unless of course something in the hardware is behaving differently and unexpectedly between those two startup flavors later on and that exposes the bug. Tend to think it's the latter.
More of a general question to the forum here ... With relying on open-source code, how much does Prusa actually develop and support on their own? With problems like this, are we relying on a community of developers on Github to sort out in their free time with Prusa having some developers on staff to finalize code or this a 100% Prusa-owned? Assuming the bootloader is proprietary as I don't see Github references to it.
Wondering if anyone has real insight on who does what.
RE: Blue screen on startup
Answered my own question by digging through the Github source. Bootloader is a .bin, so proprietary.
An interesting finding in the firmware source (not bootloader) is that this same blue screen message (UNKNOWN ERROR/Unable to show details) can be generated in the 6.4.0 firmware as a fall-through if the crash type can't be classified. I suspect Prusa replicates some of the same source in their proprietary code as what's in open source. Easier to maintain if consistent.
At least in their firmware, they're making decent use of the watchdog, stack, and hard fault handlers in the STM micro to catch what they can into error screens and crash dumps. General good practices so all the more reason to like Prusa.
That said, I suspect they have similar practices in the bootloader so it's readily debuggeable assuming they can replicate and have the desire to debug this issue.
I still prefer @mnentwig's response: Wants to sleep a little longer.
RE: Blue screen on startup
Could be a priority thing vs difficulty.
Since it's strongly points to the bootloader 2.5 and the reset button reliably avoids the blue screen, I struggle to believe that the start of the bootloader execution differs between the two flavors of startup because of what I noted from the schematics. Unless of course something in the hardware is behaving differently and unexpectedly between those two startup flavors later on and that exposes the bug. Tend to think it's the latter.
More of a general question to the forum here ... With relying on open-source code, how much does Prusa actually develop and support on their own? With problems like this, are we relying on a community of developers on Github to sort out in their free time with Prusa having some developers on staff to finalize code or this a 100% Prusa-owned? Assuming the bootloader is proprietary as I don't see Github references to it.
Wondering if anyone has real insight on who does what.
No real insight, just that I've noticed they generally ignore public PR's so leads me to believe all development is done in-house.
RE: Blue screen on startup
Please forgive the red herring: what is Github and why do so many people on the Prusa forums refer to it so often?
Could be a priority thing vs difficulty.
Since it's strongly points to the bootloader 2.5 and the reset button reliably avoids the blue screen, I struggle to believe that the start of the bootloader execution differs between the two flavors of startup because of what I noted from the schematics. Unless of course something in the hardware is behaving differently and unexpectedly between those two startup flavors later on and that exposes the bug. Tend to think it's the latter.
More of a general question to the forum here ... With relying on open-source code, how much does Prusa actually develop and support on their own? With problems like this, are we relying on a community of developers on Github to sort out in their free time with Prusa having some developers on staff to finalize code or this a 100% Prusa-owned? Assuming the bootloader is proprietary as I don't see Github references to it.
Wondering if anyone has real insight on who does what.
No real insight, just that I've noticed they generally ignore public PR's so leads me to believe all development is done in-house.
RE: Blue screen on startup
Please forgive the red herring: what is Github and why do so many people on the Prusa forums refer to it so often?
Github is a repository for software, it allows teams to collaborate and possibly share with the public. There is also a facility where issues can be recorded and shared with the developers. Also, if you are a developer yourself you can create a "pull request" (PR) which allows you to contribute to bug fixes and enhancements.