Fatal crash during printing (x2)

[AndyThirtover]

Since the 4.01 firmware upgrade, sadly the Mini has not completed a print:

[Lichtjaeger]

I have one too:

Mine happened during accessing the web monitor. Most of the requests didn't finish. Resulting in a broken page. Attempting to reload the page multiple times (during a print) will repeatedly result in this error screen.

[JustAnother1]

@Lichtjaeger You are not using the most up to date firmware. (You are on 4.0.0, most up to date is 4.0.1) You should have gottene an USB Stick with the 4.0.1 Firmware on it. It is also available on the Prusa Web Site. And yes something in the Ethernet stack went wrong. Please do a firmware update and try again. ( This is hopefully already fixed in 4.0.1)

@AndyThirtover there seems to have been an issue with handling the display. Some firmware bug. The numbers on the screen is the stack at the time of the event. Some of the numbers (those starting with 2001 are probably positions in the code memory and can be traced back to the last function call before the issue happened. Looking at that code then can help identifying the meaning of the other numbers (if necessary) Sadly the register contents and the Program Counter value are not shown.

This article https://interrupt.memfault.com/blog/cortex-m-fault-debug explains how hard faults can be debugged.

[Lichtjaeger]

Nope. Tested with both firmware versions. Same error.

[JustAnother1]

@Lichtjaeger Then please post a picture of the screen once this issue occurs with Version 4.0.1

[Lichtjaeger]

[AndyThirtover]

Here's another (this happened before the mesh leveling issue):

[JustAnother1]

From what I can see that is not the same issue, but rather close to the other one.

The Build process is a bit complicated and I did not find an *.elf file yet. I also did not find a *.map file. It only creates a 14 MB "firmware" file.I can therefore not map this to source code.

As this happens in the Display task, can you try printing without the display being attached (Ethernet, USB,..?)

[JustAnother1]

after compiling this gives some information:
arm-none-eabi-objdump -x -d -S -g firmware

@Lichtjaeger Do you have a filament run out sensor? ( The 0804fcb1 suggest that the filament run out sensor has just triggered.)

But then again the point to Null Pointer/ bool thing in PID Auto tune.

static inline bool value_bool() { return !has_value() || !!value_byte(); }
804f5f0: 2500 movs r5, #0
804f5f2: e7be b.n 804f572 <_ZN10GcodeSuite4M303Ev+0x72>
return strtof(value_ptr, nullptr);
804f5f4: f031 f822 bl 808063c
804f5f8: eeb0 8a40 vmov.f32 s16, s0
804f5fc: e7df b.n 804f5be <_ZN10GcodeSuite4M303Ev+0xbe>
return 0;


Then many of the other values make no sense at all, maybe I'm doing something wrong, or the build is not reproducible enough for my data to match your firmware.

[Lichtjaeger]

Yes, I do have a runout sensor attached. But I'm still on the same roll and it doesn't look like any false signals yet.

[freshmas]

Oh, you guys can use the ethernet for something?

EDIT: just noticed #43

[JohnnyDeer]

Hi, bluescreen bug is already fixed on newest versions of firmware, i´m closing this issue.