search

bigtreetech / BIGTREETECH-TouchScreenFirmware

support TFT35 V1.0/V1.1/V1.2/V2.0/V3.0, TFT28, TFT24 V1.1, TFT43, TFT50, TFT70
GNU General Public License v3.0
1.32k stars 1.65k forks source link

Precompiled TFT firmware throwing Error: Line Number is not Last Line Number+1, Last Line:0 #2908

Closed infodel closed 8 months ago

infodel commented 8 months ago

Description

When having the control board flashed with the newest version of Marlin (Currently v2.1.2.2) and the TFT35 E3 Display flashed with "BIGTREE_GD_TFT35_V3.0_E3.27.x.bin" the Display is currently throwing an error of "Error: Line Number is not Last Line Number+1, Last Line:0"

tft35_Error

Steps to reproduce

  1. Flash SKR-3 Control Board with Marlin Firmware 2.1.1.2
  2. Flash TFT35 E3 with BIGTREE_GD_TFT35_V3.0_E3.27.x.bin
  3. Power on and receive error on screen

Expected behavior The TFT should connect with control board and not throw error.

Actual behavior TFT is not creating connection with Control Board and Error is being displayed

Hardware Variant

TFT35 E3

TFT Firmware Version & Main Board Firmware details

BIGTREE_GD_TFT35_V3.0_E3.27.x.bin with Marlin 2.1.1.2

digant73 commented 8 months ago

it should be enough to reboot the TFT/printer after thr TFT fw is installed. If it is not working, disable command_checksum feature on config.ini (obviously you have to re-apply config.ini file). Reboot the TFT/printer, wait the TFT is connected to the mainboard, reset Marlin fw to default settings (that missing reset should be the cause of the issue) and eventually enable command_checksum again from Feature menu or maintain it disabled if you still have the issue (in this last case you have to check on Marlin side the cause for the issue)

ikke10000 commented 8 months ago

I used the exact same setup as you did and got the same error. I previously used older tft firmware with no problems, but after upgrading to the newest one I get these errors. I then tried to enable all the things in marlin as stated in config.ini but it isn't working. Also I found out it only happens when the screen has the same baudrate as the printer (in my case 25000). So that means the bug is probably in the connecting part... The fix as per stated above does work btw (disabling command_checksum) except when I re-enable command_checksum in the feature menu, the bug reappears. Are there any downsides to leaving it disabled? Edit: Sorry, I actually didn't use the EXACT same setup since I don't use the GD version.

digant73 commented 8 months ago

you can leave the command_checksum feature disabled. If everything is properly configured on your TFT and mainboard, you probably have too much EMI and you could try to reduce baudrate on both TFT and mainboard

infodel commented 8 months ago

A faulty CRTOUCH wiring ended up being the issue for me. If you still need help let me know and i could provide my config

On Sat, Mar 9, 2024 at 2:43 AM ikke10000 @.***> wrote:

I used the exact same setup as you did and got the same error. I previously used older tft firmware with no problems, but after upgrading to the newest one I get these errors. I then tried to enable all the things in marlin as stated in config.ini but it isn't working. Also I found out it only happens when the screen has the same baudrate as the printer (in my case 25000). So that means the bug is probably in the connecting part... The fix as per stated above does work btw (disabling command_checksum) except when I re-enable command_checksum in the feature menu, the bug reappears. Are there any downsides to leaving it disabled?

— Reply to this email directly, view it on GitHub https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/issues/2908#issuecomment-1986821672, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHDZ6NQEDPNO65D64RVEILYXLRUVAVCNFSM6AAAAABEHM7LUSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBWHAZDCNRXGI . You are receiving this because you authored the thread.Message ID: @.*** .com>

ikke10000 commented 8 months ago

That'd be great, thank you!

digant73 commented 8 months ago

@infodel if you fixed the issue please close this ticket. thanks

thisiskeithb commented 8 months ago

While updating to the latest TFT firmware by fixing https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/issues/2912, I also ran into this.

It's not consistent, but disabling the "Command checksum" feature under Menu -> Settings -> Feature stops the errors on the TFT.

...which is not ideal. Rolling back to older firmware seems to fix the issue, but I haven't done a git bisect to find out when this issue was introduced.

digant73 commented 8 months ago

@all previous TFT version didn't have the command_checksum feature. It has been added by #2889 even with the target to simply detect data corruption (not only to resend the command) on serial line that in many cases (with no checksum) are not detected by Marlin due the resulting commands were still valid commands. So, primary intent of the command_checksum feature is to detect and (also) to fix reliability on serial line. If the detected issue (e.g. EMI) on serial line cannot be fixed and/or the checksum errors are too frequent (becoming annoying) it is better to disable the command_checksum feature.

thisiskeithb commented 8 months ago

If the detected issue (e.g. EMI) on serial line cannot be fixed and/or the checksum errors are too frequent (becoming annoying) it is better to disable the command_checksum feature.

It should probably be disabled by default until it can be looked at & tested more. Even when shielding the stock (short) black serial cable, the errors show up randomly when there’s no real actual issue.

Edit: PR submitted: https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/pull/2917

digant73 commented 8 months ago

If the detected issue (e.g. EMI) on serial line cannot be fixed and/or the checksum errors are too frequent (becoming annoying) it is better to disable the command_checksum feature.

It should probably be disabled by default until it can be looked at & tested more. Even when shielding the stock (short) black serial cable, the errors show up randomly when there’s no real actual issue.

Edit: PR submitted: #2917

No problem to disable it by default. Were you able to verify (e.g. taking snoops on serial line or debugging on Marlin side) there is no real error? If so, it is possible that the issue is on Marlin's receiving code for which rondlh made also a fix (unfortunately not available for all ST chips) providing a DMA based version. If you have the issue on a printer with a covered ST chip, did you try to enable DMA receiving code in Marlin and see if the issue was still present?

github-actions[bot] commented 5 months ago

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.