Prusa-firmware-buddy: WATCHDOG RESET followed by crash dump(BSOD)

Created on 7 Aug 2020  路  18Comments  路  Source: prusa3d/Prusa-Firmware-Buddy

dumpdotbin.txt

Printer type - MINI

Printer firmware version - 4.2.0 (Final)

Original or Custom firmware - Original

Optional upgrades - Filament Runout Sensor

USB drive or USB/Octoprint - USB flash drive

Describe the bug - WATCHDOG RESET (RED SCREEN) followed by crash dump (BSOD)

How to reproduce - Happens shortly after mesh bed leveling and purge line is printed

Expected behavior

G-code - Doesn't matter

Crash dump file - see attached

Video - not required

20200806_154744

4.2.0 BSOD bug solved

Most helpful comment

We are constantly working on finding reason for this bug. Hopefully it will be fixed in next release. Thanks for understanding.
(Same for #771 & #791)

All 18 comments

dumpdotbin.txt

Dump.bin

Hi @ve3mic, thank you for reporting.

We are constantly working on finding reason for this bug. Hopefully it will be fixed in next release. Thanks for understanding.
(Same for #771 & #791)

I am also having this issue on v4.2.0. I tested the same 25 hour print 3x on FW v4.2.0 and it failed 3x in a row. I reverted back to FW v4.1.0 and used the exact same gcode file to test. The print was successful on the very first try on v4.1.0. I have a dump.bin from one of the v4.2.0 failures if that helps.

@inferior-minion Does your error look like in issue #771? If yes, please try FW 4.2.1 and report back. Thank you.

If there isn't more BSOD cases I麓ll close this issue soon. Please leave comment here if anyone will have BSOD on 4.2.1.

I'll bite. Got a BSOD with the same message after a Watchdog reset on 4.2.1; this was the second or third layer of the print, if that matters. Will retrieve dump from USB after print finishes... repeating the print did not make it recur, so it does not seem to be G-code specific.

IMG_0006

@vintagepc thank you for reporting, its new case.

@vintagepc Hmmm, this is really new ... tbh the second report like this on FW 4.2.1. You say it happened while printing? If it happens again, please try connecting the USB flash drive via a USB extension cable and/or use another USB flash.

Correct - During the second or third layer (I'd watched the first one go down).

Interesting you mention USB - After the reboot I went to restart the print and it choked up after selecting the print.

I was able to browse the USB files, went to select the one in question and it displayed, the preview, froze for a few seconds and then displayed an empty directory listing.

I checked the drive was securely inserted (it was) but I had to disconnect and reconnect it to get it to show again. After that I could select the file and the print completed without issue. I'd chalked that up to it being left in a bad state after the crash but it sounds like you think it might be a sketchy USB drive? (FWIW I'm using the stock one that came with the printer).

@vintagepc can you please do a fsck and may be also badblocks (nondestructive read/write) test of the USB flash drive on linux?

fsck did not report anything unusual, badblocks is grinding away now.

# fsck.vfat /dev/sdc1
fsck.fat 3.0.26 (2014-03-07)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 2
There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
  65:01/00
1) Copy original to backup
2) Copy backup to original
3) No action
? 3
/dev/sdc1: 94 files, 22496/1961976 clusters

Badblocks came back clean as well - as corroborated by the fact I was able to print the same file again without issue.

# badblocks -nsv /dev/sdc1 
Checking for bad blocks in non-destructive read-write mode
From block 0 to 7864287
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)

Hi @vintagepc,

can you please provide us your USB stick structure layout(folders, files, ...)? When you find out the way how to reproduce such an issue, that would be awesome and of course the most helpful. Basically, is before such a crash anything extraordinary during the process?

Thank you very much for your effort.

Sure - nothing untoward; I simply added a few additional sliced files to the USB drive as received from the factory.
image

So far it has not recurred but I will do my best to keep an eye out and note anything unusual surrounding the event.

Hi @vintagepc,

Thank you again for your prompt answer. After some investigation I need to ask you another questions just to confirm what could happened:

  1. Did the BSOD occur immediately after the printer startup? (< 20 seconds)
  2. Last what you did was press the knob
  3. Did you do anything else? (plug/unplug the USB stick, ethernet cable,...)

Thank you for your contribution.

I created a separate issue to make workaround more clear. All comments please write to #990, thank you.

Was this page helpful?
0 / 5 - 0 ratings