Replies: 2 comments 8 replies
-
Hi there! Glad it is (mostly) working for you! There's a known quirk in the 4.2.1 firmware that makes it slow to start (It expects the TMC drivers to reply to write requests over serial when they don't actually, at least according to the datasheet). But it is entirely possible that a recent change has broken something in the simulation. I will check. In regards to your custom 4.3.2, I do not know what changes you made so I can't really say what might be wrong. Without your sources the best advice I can offer here is to use gdb debugging of the firmware (See wiki/Getting-Started for info how to debug with vscode or CLI gdb) and breakpoint the bsod() function in appmain.cpp - then you can inspect the stack and see what is causing the BSOD. I would also suggest using the _debug_noboot .bin file when testing non-official bbf files just to eliminate any undiscovered bugs relating to signature verification. |
Beta Was this translation helpful? Give feedback.
-
OK, I think I see what is going on with 4.2.1 - if using the official .bbf the bootloader sets up the watchdog and causes a watchdog reset due to the long wait time before the TMC serial read fails. I suspect if one uses a self-compiled 4.2.1 mini_debug_noboot.bin file instead then it will work around this issue. |
Beta Was this translation helpful? Give feedback.
-
First of all Thanks a lot for Your work, impressive!
I got it working in Ubuntu 20.04.2 LTS 64bit.
I have been able to run only 4.3.0 firmware taken from prusa buddy github.
Not able to run neither a stock 4.2.1 (stucks at the end of verify then it resets) nor the attached 4.3.2 compiled and customized by me (bsod)
firmware.bbf.zip
Valerio
Beta Was this translation helpful? Give feedback.
All reactions