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.