[BUG] Printer stop midway during a print made from TFT SD or USB port.

[MLiv79]

Description

Print stop to print while printing from sd or usb of the TFT

Hardware Variant

BTT TFT 7
MB: SKR 1.4T
TMC2209 drivers

TFT Firmware Version & Main Board Firmware details

Marlin latest build 2.1.3b (but happens also with previous non beta version), Firmware latest master (2025)

Additional Information

Why instead of mocking Kisslorand about his version of the firmware and make many users crazy to find interferences in serial transmission (that don't exist) you don't cooperate with him to make a WORKING version of the Master realease of the firmware?

This is a bug old more than 1 year, 3d printer stop to print during whatever object you print if you use internal TFT SD or USB. TFT still responsive, if you cancel the print, the printer do the cancel gcode (if you enabled it) and you can move axis or do whatever you want but the print is ruined because stopped midway.
I've tried everything, changing baudrate, port, buffer size but nothing work. With some setting it stop print earlier, with some other later, but it will stop print in the first 1h max 1h and half of the print.
The only version of the firmware real working is the Kisslorand version here https://github.com/kisslorand/BTT-TFT-FW
Please cooperate to make the master newer version working too. It's not an interference issue, it's a bug in the firmware that kisslorand found a workarount at least.

[kisslorand]

@MLiv79
Thanks for the heads up, you reminded me to update my repo with some more bugfixes that I worked out but forgot to upload.

BTW, my repo is "older" than this one because I addressed the bugs earlier. It's "behind" this one only with the addition of ADVANCED_OK which brings more tears than joy, I have the "Hesitation Guard"© implemented instead which deals with the root of the problem, not with the outcome of it.

[MLiv79]

@MLiv79 Grazie per l'avviso, mi hai ricordato di aggiornare il mio repository con altre correzioni di bug che avevo elaborato ma che avevo dimenticato di caricare.

A proposito, il mio repo è "più vecchio" di questo perché ho risolto i bug prima. È "dietro" questo solo con l'aggiunta di ADVANCED_OK che porta più lacrime che gioia, ho implementato "Hesitation Guard"© che si occupa della radice del problema, non del suo risultato.

Yes your firmware is older, i can't compile it customized with visual studio code like i can with the master one but the most important thing is that your firmware WORKS. I have been able to complete a print 5h+ long after many fails with master fw.
Thanks again for your work

[Dioniusos]

Had Kisslorand's firmware for a year, not one issue with it, upgraded to newer marlin so I thought will get newsest BTT TFT firmware as well, gee.. when printing from SD or USB start throwing stupid errors , tried everything, lower boudrate, shielded cable as suggested..of course did not work, becase its not interference issue, just buggy firmware. Switched to Kissoland firmware back,..prints from SD without issues. Forgot to mentioned, had random blobs that start appearing after changed to official firmware, after reflashed with Kissoland's firmware they gone too. Will stay with working firmware. even some ppl said his firmware may contain a virus...LOL. I guess my infected printer works better...

[MLiv79]

Had Kisslorand's firmware for a year, not one issue with it, upgraded to newer marlin so I thought will get newsest BTT TFT firmware as well, gee.. when printing from SD or USB start throwing stupid errors , tried everything, lower boudrate, shielded cable as suggested..of course did not work, becase its not interference issue, just buggy firmware. Switched to Kissoland firmware back,..prints from SD without issues. Forgot to mentioned, had random blobs that start appearing after changed to official firmware, after reflashed with Kissoland's firmware they gone too. Will stay with working firmware. even some ppl said his firmware may contain a virus...LOL. I guess my infected printer works better...

Yeah and here, if you read many post about this OOOOOLD issue, contributors instead of cooperate with kisslorand to solve this issue in the master, they mock him. Incredible.
I've read all the threads about this issue, they make people crazy trying cables, settings and so on while is clearly a bug in the firmware. I hope at least that @kisslorand will keep his fork almost up to date because is the only one working.

[kisslorand]

I hope at least that @kisslorand will keep his fork almost up to date because is the only one working.

My fork is very much up to date. Today I updated it also with some edge-case bugs fixed.
Since 2023-07-31 (when I made my forked version), nothing new has been introduced in the main firmware that I hadn't already implemented and there has been no bug fix (at least not major ones) that I hadn't already fixed. Exceptions are the introduction of the 3rd toolhead status display (which introduces another bug), the infamous ADVANCED_OK together with some performance monitoring which (I guess) were implemented to diagnose the issues that the ADVANCED_OK brings.

BTW, I advise everyone using my FW to switch off ADVANCED_OK in Marlin.

Also please check out my repository for the latest version which was updated today.

[MLiv79]

I've advanced_ok enabled in marlin firmware 2.1.3b and your firmware works anyway without issues

[kisslorand]

AVANCED_OK sends unnecessary data to the TFT.

[rondlh]

Be careful with kisslorand, he's not a reliable actor, he's known for his buggy and poor quality pull requests, that are being ignored for a reason: https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/pulls

His closed source firmware is unreliable and might cause damage to your display and or printer, be warned!

[MLiv79]

Be careful with kisslorand, he's not a reliable actor, he's known for his buggy and poor quality pull requests, that are being ignored for a reason: https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/pulls

His closed source firmware is unreliable and might cause damage to your display and or printer, be warned!

Again with these messages...if it was not for kisslorand release i had thrown out of the window my Bigtreetech TFT70 because of continuos filament wasting and print failed with related loss of time. So instead of writing these you (BTT) should make a working master version of the firmware because the fact are that the only version working is the Kisslorand ones.

[rondlh]

The current status of the firmware is stable and reliable. If you prefer outdated closed source software over what you can see here, then nobody will stop you, just make sure you know what you are getting yourself into.

[MLiv79]

The current status of the firmware is stable and reliable. If you prefer outdated closed source software over what you can see here, then nobody will stop you, just make sure you know what you are getting yourself into.

The firmware is absolutely not reliable, is enough to check how many issues have been opened about this issue (with different titles) and closed without solving this issue. People have gotten bored and print from the main board's SD card, that's the only way to make the Master firmware work. From TFT USB or SD card is not working at all, even on a simple configuration with a super common Main card like mine (SKR 1.4T). So you can say whatever you want but the master firmware it is anything but stable, reliable and functional.

[kisslorand]

@MLiv79

Do not bother with @rondlh. He's a goofy sh!t-eating d!ck-head of a troll. He's just frustrated that he doesn't have the source code for my "Hesitation Guard" implementation. He is not a BTT employee, he's just a puppet of some other hot-shot around here, he has ZERO pull request merged into this repository at this very moment (yes, that's how good he is analysing other people's work).
Really, do yourself a favor, ignore him. Whoever is fool enough to listen to his rabid bark deserves to stay with the FW from this repository.

BTW, check out my repository, I just updated it today with a really itsy-bitsy tiny bug fix (inherited from here) and some FW size reduction for TFTs with only one serial port.

[rondlh]

Why instead of mocking Kisslorand about his version of the firmware and make many users crazy to find interferences in serial transmission (that don't exist) you don't cooperate with him to make a WORKING version of the Master realease of the firmware?

There is no way of cooperating with Kisslorand because he's a snake oil salesman who lacks coding and social skills. There is nothing behind his claims, only lies and empty words. That's why he has to hide behind his closed source lies and claims of miraculous performance and stability.
I use the BTT open source firmware on 4 of my printers, with 3 different versions of the hardware (BTT TFT35 V3.0, BTT GD TFT35 V3.0 and MKS TFT3 3.5 V1.0), the TFT works perfectly on all of them. The bugfixes I submitted are only minor issues relevant for print farms.

I'm not mocking anybody, Kisslorand does a great job at mocking himself without my help.

BTW, there are several reports of Kisslorand's firmware bricking printers and TFTs, I tried his firmware and soon after my TFT was bricked, but perhaps you have more luck than me. I strongly recommend to stay away from running closed source firmwares from third parties, it can break your hardware and even cause fires. The open source community is far smarter than one single individual who doesn't even do peer reviews.

[kisslorand]

@MLiv79

Check out again my repository, you might like the new stuff. :)

Aside the speed increase I included a fix for the timer overflow issue. It's done in a proper way, not as in the abomination that our beloved cockroach did in PR #2967, which although it fixes part of it but doing it creates other, previously not existing bugs.
Yeah, so much about making this FW "The current status of the firmware is stable and reliable".

On the same note of "poor quality pull requests", PR #2967 allegedly fixes an inconvenience by "jump to high temp without clicking 20 times". It fixes only that PR's author own stupidity, you can have any desired temperature by 4~5 clicks:

1. press the place on the TFT where the desired and actual temp is displayed (between the "-" and "+" buttons) and the numpad comes up (1 click)
2. input the value of your desired temp (2 or 3 clicks)
3. press the OK button, done in less than 2 seconds

I am speechless what the "fix" is for in that pull request...

One thing that PR fixes indeed, it is the TFT freeze if you long press the upper part of the TFT for the "Notifications" page to come up. But that also had to be done in a twisted way. In "menu.c" line 1222 is this code if (tempkey2 < COUNT(getCurMenuItems()->items)) which translates to if (tempkey2 < (sizeof(getCurMenuItems()->items) / sizeof(getCurMenuItems()->items[0])). It would have been just easier to write if (tempkey2 < ITEM_PER_PAGE which translates simply to if (tempkey2 < 8). I am out of clue why to put extra weight on the MCU... it must be his "professional" approach to ensure the greatness of this FW.

I never thought about the timer overflow as being a bug but I did it in the spirit of not to be "outdated". Anyhow, who would use his printer more than 54 days (this is the period for the timer to overflow) other than maybe print farms? Do print farms really use printers with Marlin and TFT with this FW these days???

[Dioniusos]

Thank you Kisslorand for updatring your repo, will get updated firmware for my oldie :)

[rondlh]

Thanks for the tip about the temp settings and reviewing my PR, just take what you like, that's why I share it, you're welcome!

Obviously you are wrong about "menu.c", but that's probably a bit over your head.

Yes, print farms use Marlin and also the BTT displays, but they certainly will not use any closed source firmware.

@everyone
DON'T USE CLOSED SOURCED FIRMWARE ON YOUR PRINTER OR DISPLAY, IT CAN CAUSE HARDWARE DAMAGE OR A FIRE
KISSLORAND'S CLOSED SOURCE FIRMWARE IS OF POOR QUALITY AND HAS NOT BEEN PEER REVIEWED

[digant73]

@MLiv79 You reported the printing is stopped but I need some details for a further investigation. Do you see some errors reported on screen during the print or just before the print is frozen? or everything is fine but then there is no more printing activity? Do you see some activity on Monitoring menu? Attach a picture, or even better a video of few seconds, of the Monitoring page (the one reporting some KPIs such as Free TX slots etc.). A print failed/frozen doesn't mean the root cause is only one for all users and any HW. Is there a list of some bug reports you could provide fitting the issue you are facing with I could double check?

[MLiv79]

Thanks for the tip about the temp settings and reviewing my PR, just take what you like, that's why I share it, you're welcome!

Obviously you are wrong about "menu.c", but that's probably a bit over your head.

Yes, print farms use Marlin and also the BTT displays, but they certainly will not use any closed source firmware.

@everyone DON'T USE CLOSED SOURCED FIRMWARE ON YOUR PRINTER OR DISPLAY, IT CAN CAUSE HARDWARE DAMAGE OR A FIRE KISSLORAND'S CLOSED SOURCE FIRMWARE IS OF POOR QUALITY AND HAS NOT BEEN PEER REVIEWED

A fire...funny ahahahha. Anyway fire or not fire, if ain't working like with the master firmware is crap totally useless.

[MLiv79]

@MLiv79 You reported the printing is stopped but I need some details for a further investigation. Do you see some errors reported on screen during the print or just before the print is frozen? or everything is fine but then there is no more printing activity? Do you see some activity on Monitoring menu? Attach a picture, or even better a video of few seconds, of the Monitoring page (the one reporting some KPIs such as Free TX slots etc.). A print failed/frozen doesn't mean the root cause is only one for all users and any HW. Is there a list of some bug reports you could provide fitting the issue you are facing with I could double check?

No errors on screen, no free tx slots issues, i checked many times in my tests the info screen while printing and when printer freeze on part, free tx slots are the same as when running fine. I've tested many combination in config increasing, decreasing free tx but nothing works. And now that i've a working printer with kisslorand firmware, forgive me but i've no time again to reflash the master firmware wasting time and filament to make a video that tells nothing. Thanks anyway @digant73

[digant73]

ok, so apparently in your case it seems a bug on fetching data. If possible share a print file I could test. If you have a WiFi module plugged in the TFT, did you ever try to print from it and verified if it was working without any issue?

[MLiv79]

ok, so apparently in your case it seems a bug on fetching data. If possible share a print file I could test. If you have a WiFi module plugged in the TFT, did you ever try to print from it and verified if it was working without any issue?

No i never tried to print through wifi because i don't have the module, as i wrote if i print from skr 1.4t sd slot print works flawlessly, the issue is related of printing from tft usb or sd slot. It happens with all files, but i can attach one for example
It doesn't allow me to attach gcode files, i renamed it as jpg

[digant73]

ok thanks. I will try this file. I see it is generated by SuperSlicer. Maybe the issue could be related to the gcode parser. If possible, provide also your config.ini file so I will use the same features on my printer.
So just to recap your issue:

1. the print starts and everything is ok (no error displayed on screen)
2. after some time, it seems no gcode from file is sent to the printer
3. the TFT is still in the Printing menu but there is no print progress
4. the TFT is not frozen. You can move to the Monitoring menu and you see:
   • Buffered gcodes: it is 0 (maybe it is sometimes 1 if a polling gcode such as M105 is sent by TFT)
   • Pending gcodes: it is 0 for most of the time (it means that no gcode is read and sent from SD/USB card)
   • Free TX slots: it is >0 for most of the time (it means that a gcode can be sent to the printer)
5. you can move and use menus (e.g. move on Terminal, send a command, the command is executed by the printer and the reply (e.g. ok) is finally received by the TFT

Please confirm or correct the above steps.
Don't forget to provide your current config.ini file

[rondlh]

It doesn't allow me to attach gcode files, i renamed it as jpg

@MLiv79 You can ZIP any file and upload it here, no need to rename the file.

I used several LPC1769 boards in the past (SGEN_L V2.0) and found them to be very reliable in combination with the TFT. Something I cannot say about all STM32 based boards.

[MLiv79]

ok thanks. I will try this file. I see it is generated by SuperSlicer. Maybe the issue could be related to the gcode parser. If possible, provide also your config.ini file so I will use the same features on my printer. So just to recap your issue:

1. the print starts and everything is ok (no error displayed on screen)

2. after some time, it seems no gcode from file is sent to the printer

3. the TFT is still in the Printing menu but there is no print progress

4. the TFT is not frozen. You can move to the Monitoring menu and you see:

   • Buffered gcodes: it is 0 (maybe it is sometimes 1 if a polling gcode such as M105 is sent by TFT)
   • Pending gcodes: it is 0 for most of the time (it means that no gcode is read and sent from SD/USB card)
   • Free TX slots: it is >0 for most of the time (it means that a gcode can be sent to the printer)

5. you can move and use menus (e.g. move on Terminal, send a command, the command is executed by the printer and the reply (e.g. ok) is finally received by the TFT

Please confirm or correct the above steps. Don't forget to provide your current config.ini file

Yes to all

Files.zip

[digant73]

Had Kisslorand's firmware for a year, not one issue with it, upgraded to newer marlin so I thought will get newsest BTT TFT firmware as well, gee.. when printing from SD or USB start throwing stupid errors , tried everything, lower boudrate, shielded cable as suggested..of course did not work, becase its not interference issue, just buggy firmware. Switched to Kissoland firmware back,..prints from SD without issues. Forgot to mentioned, had random blobs that start appearing after changed to official firmware, after reflashed with Kissoland's firmware they gone too. Will stay with working firmware. even some ppl said his firmware may contain a virus...LOL. I guess my infected printer works better...

@Dioniusos
could you please attach your config.ini? Can you provide details of the issue? I mean some examples of the errors on screen, a screenshot of the Monitoring menu etc.
Something that I verified in the past sniffing on serial line is that the messages were ok while the mainboard was reporting some errors. I had the feeling that the mainboard is not able to properly read on serial line when processing some gcodes (errors are usually at the beginning of the gcode, e.g. "M14 E" instead of "M114 E"). Probably a delay between messages could fix that issue but it is more a workaround on TFT for an issue on mainboard. I could provide the fw with that workaround but I need some testing and feedbacks from users having the issue

[digant73]

@MLiv79 I tried you gcode files more than 10 times without any freeze or other issues. Based on your report (in particular you reported no error on screen but only no more gcode fetched from SD/USB stick sent to the mainboard) I can isolate a possible issue on two features. I made some changes for your TFT 70 v3 (I think no GD). Attached the fw.
If you could test it and let me know if it fixes your hang on printing is welcome. Use the same config.ini file you provided me.
You don't need to waste filament. Simply remove it, disable runout feature (if enabled), and lower the temperature (hot end and bed) once the print is started (in my printers I disabled the cold extrusion feature so I can lower the temperatures to any low value such as 30°C)

BIGTREE_TFT70_V3.0.27.x.zip

[rondlh]

I had the feeling that the mainboard is not able to properly read on serial line when processing some gcodes (errors are usually at the beginning of the gcode, e.g. "M14 E" instead of "M114 E"). Probably a delay between messages could fix that issue but it is more a workaround on TFT for an issue on mainboard. I could provide the fw with that workaround but I need some testing and feedbacks from users having the issue

Kisslorand's firmware is considerably slower than the official firmware. His simplified implementation of serial DMA (he calls it "hesitation guard") has only 1 command buffer. This is so slow that it automatically adds delays between the commands. The faster approach use here is to fill all Marlin command buffers and let Marlin handle the rest, but this puts more stress on the serial connection. So if the issue is a serial connection that is not 100% stable, then that would explain the issue. We can always slow down the TFT if needed.

[MLiv79]

@MLiv79 I tried you gcode files more than 10 times without any freeze or other issues. Based on your report (in particular you reported no error on screen but only no more gcode fetched from SD/USB stick sent to the mainboard) I can isolate a possible issue on two features. I made some changes for your TFT 70 v3 (I think no GD). Attached the fw. If you could test it and let me know if it fixes your hang on printing is welcome. Use the same config.ini file you provided me. You don't need to waste filament. Simply remove it, disable runout feature (if enabled), and lower the temperature (hot end and bed) once the print is started (in my printers I disabled the cold extrusion feature so I can lower the temperatures to any low value such as 30°C)

BIGTREE_TFT70_V3.0.27.x.zip

Thanks, as soon as i've a little bit of time i'll test the firmware

[digant73]

@MLiv79 I tried you gcode files more than 10 times without any freeze or other issues. Based on your report (in particular you reported no error on screen but only no more gcode fetched from SD/USB stick sent to the mainboard) I can isolate a possible issue on two features. I made some changes for your TFT 70 v3 (I think no GD). Attached the fw. If you could test it and let me know if it fixes your hang on printing is welcome. Use the same config.ini file you provided me. You don't need to waste filament. Simply remove it, disable runout feature (if enabled), and lower the temperature (hot end and bed) once the print is started (in my printers I disabled the cold extrusion feature so I can lower the temperatures to any low value such as 30°C)
BIGTREE_TFT70_V3.0.27.x.zip

Thanks, as soon as i've a little bit of time i'll test the firmware

in case the issue is still there, provide a picture (or a short video) of the Monitoring menu (the menu reporting pending gcodes, free TX slots etc.). Also (important) get a picture of the temperatures (current and target).
Also, if the issue is still there, you could try to start a print and then move out from the Printing menu (e.g. press on More menu and remain on that menu) and see if the issue is no more present

[digant73]

attached PR #2970 that could fix your issue.

config.ini has been updated with the new param tx_delay and tx_prefetch. I used a delay of 3 ms. I disabled advanced_ok and enabled command_checksum (to detect even a corrupted but valid command). if the issue is fixed, try to lower the delay (possibly 1 is good). After that do the same with advanced_ok enabled, if you want to use it. In that case start with a value of 6 for tx_delay.
You can change the value of tx_delay even at runtime from the Feature menu.

PR2970.zip