[BUG] The print freezes on SKR mini 2.0

[pv501977]

Bug Description

The printer randomly freezes during print the model xyzCalibration_cube. I made 3 prints, but they all failed.

Machine

• SKR mini E3 v2.0 (TMC2209) & TFT35 v3.0
• Marlin 2.0.7.2 and 2.0.8.0 bugfix

Issue

• random freezes that can be reproduced
• I used the same gcode, but it freezes on different possition
• when freezing the print head stops moving
• heaters and fans however stay ON!! which is a POSSIBLE FIRE HAZARD
• I can used the TFT35 to pause/stop print and for moving axis
• I can used SW for control
• I did not do reset the SKR

I found similar troubles - #17161, #18117, #15337, all was closed.

Configuration Files

https://www.dropbox.com/s/u2vyld5gthd1c94/2021-01-04-Marlin-2.0.8.0-bugfix.zip?dl=0
https://www.dropbox.com/s/1p0kpcp1wfolba3/2021-01-03-Marlin-2.0.7.2.zip?dl=0

Steps to Reproduce

1. Use the my configuration
2. Start print gcode file from Pronterface
3. Wait

Expected behavior:

The model will be printed

Actual behavior:

Print starts and after some time freezes.

Additional Information

Images with printed model:
https://www.dropbox.com/s/pvzjfvkfqc69ly5/2021-01-03-Marlin-2.0.7.2-cube.jpg?dl=0
https://www.dropbox.com/s/rinwxa9gmiax7bs/2021-01-04-Marlin-2.0.8.0-bugfix-1.jpg?dl=0
https://www.dropbox.com/s/rinwxa9gmiax7bs/2021-01-04-Marlin-2.0.8.0-bugfix-1.jpg?dl=0

Video
https://www.dropbox.com/s/xd2kz8x1kwadidv/2021-01-04-Marlin-2.0.8.0-bugfix.mp4?dl=0

[pv501977]

Here is the gcode file that I used
https://www.dropbox.com/s/refflq5ag5n3319/xyzCalibration_cube.gcode?dl=0

[Bastlwastl84]

my TFT loosing often the connection. thats a TFT FW problem at myself and printing with marlin-mode is working. by mine Marlin doesnt like now to controll the fans

[pv501977]

I don't have a problem with TFT and fans.

I did next tests

I used the default configuration from config\examples\Creality\Ender-3\BigTreeTech SKR Mini E3 2.0 + small modifications (TEMP_SENSOR, ENDSTOP_INVERTING, DEFAULT_AXIS_STEPS_PER_UNIT, FIX_MOUNTED_PROBE, CHOPPER_DEFAULT_12V)

1. I printed from Pronterface - the print freezed again
2. I printed from SD card in SKR mini - the print was finished correctly !!!

I used the configuration shared in this case again

• I printed from SD card - the print was finished correctly !!!

I think that the problem could be with USB serial. The print from PC crashed always.

In SKR mini guide I found note: "Follow this comment if you are experiencing freezing mid print"
My notes to the comment:

• I have MONITOR_DRIVER_STATUS disabled
• Marlin 2.0.8 use modified libmaple usart_private.h file
• Marlin case UART IRQ Priority + Error Handling for Overrun, Framing and Parity  #19301 used the 'UART fix'

Do you have any idea how could I help confirm that the problem is in USB serial

Note: when the print freezed, I was able (by Pronterface and TFT) control the print - pause, resume, move axis,.. but when I used resume, the print did not continue. Looks like it doesn't know what to print.

[pv501977]

I tried use this fix, but it did not help. It freezed again (print from Pronterface).

[kad]

Observed couple of times similar thing on my SKR mini MZ (which is same schematically as SKR mini E3 V2.0) with current bugfix-2.0.x branch build (FIRMWARE_NAME:Marlin bugfix-2.0.x (Jan 9 2021 18:56:47)).
Printer stops, not reacting to OctoPrint commands, but sends the temperature information, until knob on LCD pressed. then printer continues. on status line there is no messages. Serial log from OctoPrint:

2021-01-17 19:21:05,673 - Send: N41353 G1 X144.233 Y135.946 E1555.83923*90
2021-01-17 19:21:05,783 - Recv:  T:229.69 /230.00 @:92
2021-01-17 19:21:05,854 - Recv: ok
2021-01-17 19:21:05,854 - Send: N41354 G1 X144.46 Y135.552 E1555.85511*111
2021-01-17 19:21:07,783 - Recv:  T:229.56 /230.00 @:94
2021-01-17 19:21:09,783 - Recv:  T:229.37 /230.00 @:96
2021-01-17 19:21:09,784 - Communication timeout while printing, trying to trigger response from printer. Configure long running comm
ands or increase communication timeout if that happens regularly on specific commands or long moves.
2021-01-17 19:21:09,785 - Send: N41355 M105*33
2021-01-17 19:21:11,783 - Recv:  T:229.19 /230.00 @:99
2021-01-17 19:21:13,783 - Recv:  T:229.19 /230.00 @:99
2021-01-17 19:21:13,784 - Communication timeout while printing, trying to trigger response from printer. Configure long running comm
ands or increase communication timeout if that happens regularly on specific commands or long moves.
2021-01-17 19:21:13,785 - Send: N41356 M105*34
2021-01-17 19:21:15,783 - Recv:  T:229.62 /230.00 @:91
2021-01-17 19:21:17,784 - Recv:  T:229.62 /230.00 @:93
...
2021-01-17 20:19:48,490 - Recv:  T:230.00 /230.00 @:89
2021-01-17 20:19:50,495 - Recv:  T:230.06 /230.00 @:89
2021-01-17 20:19:50,495 - Communication timeout while printing, trying to trigger response from printer. Configure long running comm
ands or increase communication timeout if that happens regularly on specific commands or long moves.
2021-01-17 20:19:50,538 - Recv: ok
2021-01-17 20:19:50,540 - Recv: ok T:230.06 /230.00 @:89
2021-01-17 20:19:50,543 - Recv: ok T:230.06 /230.00 @:89
2021-01-17 20:19:50,545 - Recv: ok T:230.06 /230.00 @:89
2021-01-17 20:19:50,548 - Recv: ok T:230.06 /230.00 @:89
2021-01-17 20:19:50,551 - Recv: ok T:230.06 /230.00 @:89
2021-01-17 20:19:50,553 - Recv: ok T:230.06 /230.00 @:89
2021-01-17 20:19:50,555 - Recv: ok T:230.06 /230.00 @:89
2021-01-17 20:19:50,556 - Send: N41387 M105*46
2021-01-17 20:19:50,558 - Recv: ok T:230.06 /230.00 @:89
2021-01-17 20:19:50,559 - Send: N41388 G1 X144.538 Y135.107 E1555.87088*81
2021-01-17 20:19:50,561 - Recv: ok T:230.06 /230.00 @:89

[Bastlwastl84]

Mine SKR Mini E3 V2 has the issue, that TFT Prints sometimes freezes and my ESP01 can read the values, but sent commands will not accepted and the TFT writes at top "Bitte warten ..." (Please wait ...). While printing with MarlinMode works, but not with TFT35 E3 V3.

[kad]

I found in BTT's SKR mini E3 / SKR mini MZ repositories few strange commits, that potentially can be related. e.g. bigtreetech/BIGTREETECH-SKR-MINI-MZ@96ffe0b#diff-fdfec4ae4090e7bbb634ba60b14b927fb1d2a4b22e5d58c33fbfa88336488861 -- so if it is somehow screwed with beeper/speaker and timers on SKR mini boards, that might explain.

Reasons for suspecting is because I again noticed today "a pause until knob is clicked" situation, and checked logs.
I see some bridge line printed, where fan set to full speed, then back to 50%, and after that return got timeout.
So, might be some fan related timers have race conditions?

2021-01-18 17:47:18,939 - Send: N187639 G1 X85.708 Y114.94*16
2021-01-18 17:47:18,967 - Recv: ok
2021-01-18 17:47:18,968 - Send: N187640 G1 X86.45 Y114.94*35
2021-01-18 17:47:19,013 - Recv: ok
2021-01-18 17:47:19,014 - Send: N187641 M106 S255*88
2021-01-18 17:47:19,015 - Recv: M106 P0 S255
2021-01-18 17:47:19,016 - Recv: ok
2021-01-18 17:47:19,017 - Send: N187642 G1 F750 X86.45 Y121.597 E3951.34988*62
2021-01-18 17:47:19,062 - Recv:  T:229.94 /230.00 @:89
2021-01-18 17:47:19,148 - Recv: ok
2021-01-18 17:47:19,149 - Send: N187643 M106 S127.5*71
2021-01-18 17:47:21,062 - Recv:  T:229.87 /230.00 @:91
2021-01-18 17:47:23,077 - Recv:  T:230.12 /230.00 @:87
2021-01-18 17:47:23,077 - Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeo
ut if that happens regularly on specific commands or long moves.
2021-01-18 17:47:23,079 - Send: N187644 M105*31

[sjasonsmith]

@kad, for your MX board:

The fans on the MX board seem to be on Timer8, so adding this line from the BTT commit would be worth trying:

-DTONE_TIMER=4

You probably don't need the TONE_CHANNEL change, it should default to that value anyway.

Be careful when applying this change to other boards. The Maple framework ignores TONE_TIMER if BEEPER_PIN is mapped to a pin with a timer defined. I checked the two pins I found in pins headers and they both did not have timers specified.

[sjasonsmith]

@pv501977

Can you test again with the following changes:

1. Disconnect TFT display
2. Make sure MONITOR_DRIVER_STATUS is still disabled

Previous hangs were related to UART interrupts. These are used by your TFT display and TMC drivers, but NOT by USB on this board.

By eliminating all use of UARTs during prints, we can eliminate that as a cause of the hang. By not requiring a TFT display to reproduce it is also for others to help test.

[kad]

@kad, for your MX board:

The fans on the MX board seem to be on Timer8, so adding this line from the BTT commit would be worth trying:

Reminder: SKR mini MZ and SKR mini E3 2.0 schematically are equal. Just difference in physical layout.

BTT's SKR mini E3 repository has similar commits. bigtreetech/BIGTREETECH-SKR-mini-E3@1fc9de3

Be careful when applying this change to other boards. The Maple framework ignores TONE_TIMER if BEEPER_PIN is mapped to a pin with a timer defined. I checked the two pins I found in pins headers and they both did not have timers specified.

Thing that we are observing might be related to changes of stm32 / mapple upgrade that was done after 2.0.7.2 release... but just my speculation. I'll probably try to rebuild with [email protected] and observe.

[kad]

You probably don't need the TONE_CHANNEL change, it should default to that value anyway.

Actually, that is one of the changes in maple:

--- [email protected]/STM32F1/cores/maple/tone.cpp  2019-03-30 21:44:22.000000000 +0200
+++ framework-arduinoststm32-maple/STM32F1/cores/maple/tone.cpp 2020-11-29 14:25:42.000000000 +0200
@@ -31,7 +31,7 @@
        #define TONE_TIMER 8
        #endif
        #ifndef TONE_CHANNEL
-       #define TONE_CHANNEL 8
+       #define TONE_CHANNEL 4
        #endif

        HardwareTimer TTimer1(1), TTimer2(2), TTimer3(3), TTimer4(4),TTimer5(5), TTimer6(6), TTimer7(7), TTimer8(8);

@sjasonsmith do you have knowledge of timer parts in HAL/stm32? this defaults changes in maple might explain why timers got screwed.

[sjasonsmith]

STM32 timers never have more than 4 timers channels. That was a bug in Maple. It makes sense now that they had to override it, because 8 is invalid.

[sjasonsmith]

I am concerned that this thread is all about SPEAKER and TONE, even though the original reporter did not have SPEAKER enabled. Let’s try to focus on hangs that occur witH SPEAKER disabled.

[kad]

I am concerned that this thread is all about SPEAKER and TONE, even though the original reporter did not have SPEAKER enabled. Let’s try to focus on hangs that occur witH SPEAKER disabled.

I have also speaker disabled, and soft pwm enabled. And still same scenario: print over USB, at some point printer stops responding with fans/heaters on.
In my case pressing on the knob triggers response, so my speculation was, that is because of "releasing" some timers, which other BTT users noticed between FAN control and sound producing code (speaker or beeper).

Biggest difference between my config and @pv501977 seems to be only in bltouch vs fixed mounted sensor. This means that in my setup Timer1 seems to be used for servo0.

But then, according to your comment that it should be only 4 timers:
https://github.com/MarlinFirmware/Marlin/blob/2.0.x/Marlin/src/HAL/STM32F1/timers.h#L68-L74
stm32f103rct6 that is used on BTT mini boards will result STEP_TIMER_NUM=4 or =5?

[sjasonsmith]

I didn’t say there were 4 timers. I said that each timer never has more than 4 channels.

edit: Oops, I did say 4 timers, but meant 4 channels ;)

[kad]

I didn’t say there were 4 timers. I said that each timer never has more than 4 channels.

well, it was not so cleanly stated in previous reply: "STM32 timers never have more than 4 timers.".
Anyway, it seems time for me to read in more detail stm32f103rct datasheet about timers supported there.

[sjasonsmith]

, it was not so cleanly stated in previous reply:

Oops, that was a typo on my part. I went back and edited my post to avoid confusing anyone else with it.

[pv501977]

@sjasonsmith

On Saturday I upgraded TFT35 FW to the latest version (Master from 17.1.)

I did 2 tests now

• I printed xyzCalibration_cube on SKR mini with the Master FW 2.0.8 (other settings than I shared here, MONITOR_DRIVER_STATUS disabled, Linear Advance enabled, new settings here)
• I used FW 2.0.7.2 again with the settings that I shared here. Note: without reset eeprom

I printed from PC again and both prints finished correctly!

I will use Marlin 2.0.8 again and I will do more tests.

Should I try use older TFT35 FW and do tests with and without TFT35 display?

[pv501977]

@sjasonsmith

I did next 2 tests. I used Marlin 2.0.8, how I wrote.

I printed from PC - with and without connected TFT (I disconnected both cables from the TFT display).
Both prints failed - freezed again!

I can share the video from the SW.

• When it freezed, I could pause print, move Z axis 10mm high

[kad]

I printed from PC - with and without connected TFT (I disconnected both cables from the TFT display).
Both prints failed - freezed again!

in your software that you use on PC, is it possible to write serial log ? it would be interesting to see if some similarities with
octoprint logs. Also, it might be related with software behaviour - octoprint in case of detected timeouts will wait and continue as soon as it gets response. Your PC software might abort after some timeout and not continue. E.g. commands on LCD might unblock serial responses, but PC software already gave up.

[pv501977]

I'm using Pronterface, it supports serial log, but during print there are no added new commands. I will try install Octoprint.

[kad]

I'm using Pronterface, it supports serial log, but during print there are no added new commands. I will try install Octoprint.

Well, if Proterface supports log - enable it please for your next trials, and let's check what is going on at the time when print freezes.

BTW, in UI of Pronterface, do you see status of print when it freezes? is it "printing/" or any error message?

[pv501977]

I did long-term prints. I used Octoprint (on PC and RPI) - Pronterface does not support the correct serial log.

Results:

• RPI - 4 prints finished correctly
• PC - the print frozen

The logs files from PC Octoprint : here

Notes:

• I'm not sure that "the print frozees" is Marlin problem.
• The print from RPI worked correctly so I think that the problem could be in my PC
• On my PC sometimes freezing the keyboard. I have to restart it by SW devcon. I don't know what the cause is. Electronic interference maybee?
• The keyboard was also frozen when I last printed from the PC (but not during xyzCalibration_cube printing when I created this case)
• I think that Anet A8 has better/more durable USB chip/windows driver than SKR mini - I printed 2 years without freezing.

I think that this case is possible to close.
I will do next 3D print tests. I will try eliminate freezing the keyboard -> and prints too.

Is it possible to add to Marlin next security check? Similar as 'Thermal Runaway, system stopped! Heater_ID: bed'

• Stop heating when the Marlin stop receiving the commands during print -> timeout?

[jbarss]

I am having the exact same issue. Mine started randomly after nearly two weeks of perfectly sucessful prints with the Ender 3 Pro, with MiniSKR V3 and TFT 35 touch screen. I just updated the firmware to the most recent available on Github today, and the problem persists. Sometimes it happens in the first hour, sometimes it happens at hour 23. Its totally random. I am not a programmer so please be gentle if I am asking basic questions here. Printing from Micro SD via USB card adapter.

What's the recommended solution? I see several tickets open and closed over the last year, but nothing that seems to work for everyone.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.