Receiving this error consistently - Please flash your TFT screen: version mismatch - build 61166 found but expected 61

[jcgrim]

I have read through every tutorial, every readme, all open and closed issues and googled all variations I could think of and haven't been able to find a solution, so hoping someone can help!

Printer: Creality CR-6SE (bought on Amazon well after Kickstarter) Motherboard: v4.5.2 Starting TFT DWIN: T5L1 DGUS2 v1.4 2019.04.18 (identified using an empty DWIN direct on the microSD)

Initial Steps followed:

1. Readme instructions for flashing TFT with v1.4 say to use the firmware included with the proper Community Software zip file.
2. Downloaded appropriate zip file based on my hardware config: CF6.1-Final-cr6-se-v4.5.2-mb-2021-06-04-16-52.zip
3. Using a Sandisk SDHC1 8GB microSD, I formatted using the provided instructions in the Readme and copied over the DWIN_SET folder and copied the files from the Kernel folder to the DWIN_SET folder as well.
4. Put the MicroSD card in the display and turned the printer on.
5. Got the appropriate Blue screen showing files were copied successfully, the "END" indicator and the top of the screen now showing T5L1 DGUS2 v3.5 2020.07.30
6. Based on instructions, I turned the printer off and back on to ensure all the DWIN files copied over properly. (see screen shot of updated TFT firmware)
7. Unplugged the screen, removed the microSD Card and plugged the screen back in.
8. Using a separate ScanDisk SDHC 16GB SD Card, formatted following the provided instructions, copied over the bin file from the zip file outlined above to the SD Cards root directory.
9. Put the SD Card in the printer and turned the printer on.
10. The Community splash screen was displayed on the printer for 15-20 seconds and then the screen with the progress bar came up.
11. New Community firmware loaded, however this is where I get 3 loud beeps, hotend blue LED flashing and the error message scrolling on the screen "Please flash your TFT screen: version mismatch - build 61166 found but expected 61"
12. I am able to connect to the printer with Octoprint on a RaspberryPI and I was able to complete the bed leveling. Haven't tried to send a print yet to see if it would print correctly even with the message.

The error message came up the first time and has come up regardless of any troubleshooting steps I have tried, however here are other things I have tried before making this post:

• I have tried 3 different MicroSD cards for the TFT firmware load and 3 different SD Cards for the Motherboard Firmware load, all of different sizes and all formatted properly.
• I've tried loading the Motherboard firmware first and then reloading the TFT firmware.
• I tried flashing the TFT without the Kernel files in the DWIN directory.
• I've tried using the REFACTORED firmware (flashing it on top of the v3.5 that seemed to load successfully)
• I've used an empty DWIN directory on the SD Card to confirm that v3.5 is loaded.
• I've turned the printer on and off with different combinations of the SD Cards inserted to ensure the firmware was fully loaded to both the TFT and motherboard.

I haven't yet tried any other versions of the zip file given they don't match my hardware configuration.

Attached are pictures of the screen and motherboard for reference.

I've read that this is a "soft" error message and doesn't impact the ability to print, however the flashing LED and beep is not something I just want to live with.

I've also read that there might be a way to compile this error message out of the firmware, however I have never tried compiling this type of code and wouldn't know where to look to find the error nor know how to take it out before re-compiling. I'm willing to learn if there are any guides out there of if anyone could share the steps to do that.

I'm willing to try any other troubleshooting as this didn't seem like a common issue in all my research.

[ritchiedc]

Was the rpi connected when you flashed? If so have you blocked the 5v line in the usb connector?

[jcgrim]

No, so I kept the RaspberryPi disconnected from the very start to ensure it didn't cause any issues and to be sure it wasn't an added variable if something didn't work. The only time I have connected it was after reading that the message was just a warning to see if the printer would still function.

The one other weird thing is, if I have the rpi connected when I turn on the printer, the tft screen stays on the splash screen and doesn't boot up. However if I connect it after the printer is on and booted to the screen above, then it works.

I saw the other posts on blocking the 5V line in the USB connector, however it's a mini USB connector so I haven't figure out how people are doing that.

[ritchiedc]

A small piece of electrical tape at the big end that plugs into the rpi is what most people do. I split open the cable, took a chance and cut the red wire. You have to be very careful opening it up though.

[jcgrim]

Anyone have any additional thoughts. So far I haven't been able to get past this and there doesn't appear to be a way to go back. Hoping there is at least some way out of this error/issue...

[ritchiedc]

Can you post a picture of the settings->info screen?

[Sebazzz]

Sorry this issue slipped my mind!

This issue seems to be very similar to #65 - we were never able to resolve it, though you can try the steps outlined there. It seems to be a case of faulty hardware, with some sectors of the EEPROM not being writable anymore.

[ritchiedc]

If you want to try compiling your firmware Sebazzz has a guide at https://damsteen.nl/blog/2021/01/08/how-to-compile-cr6community-marlin-with-vscode-platformio.

I believe you can bypass the test by a one line change. I haven't tested it other than compiling. There are more elegant ways to fix it but I wanted a simple single line change. It causes the version test a few lines down to always pass.

File: Marlin\src\lcd\extui\dgus_creality\DGUSScreenHandler.cpp

Line 1214: is: uint16_t actualScreenVersion = swap16((uint16_t)val_ptr); change to: uint16_t actualScreenVersion = EXPECTED_UI_VERSION_MAJOR;

[ElMyggo]

I have the same issue and i download this 6.1 firmware and update only the motherboard and now it has no warning or beep

https://github.com/CR6Community/Marlin/releases/tag/v2.0.8.1-cr6-community-release-6.1

aahhh se now that you have different motherboard... i have 1.1.0.3 and i use other source file...

[ElMyggo]

Here is the updated touchscreen firmware i use https://github.com/CR6Community/CR-6-touchscreen/releases/tag/61F_220622_v1

[jcgrim]

Hey everyone, I first want to say thank you to everyone for the quick and detailed responses! Your responses have helped solve every issue I was facing.

So as a quick followup for anyone who finds this post when trying to resolve a similar issue, here is a quick summary of what ended up working:

1. The Community TFT upgrade worked fine (most likely it was fine from the first time I installed it as I got all the right info on the firmware upgrade screen).
2. Where things seem to have been an issue was with all different variations of the Motherboard firmware. None of them would recognize that the TFT firmware was updated properly.

So what finally worked was following @ritchiedc post above to manually change the one line in the Source Code and manually compiling it myself. Let me first say I know very little about coding and what I do know is very outdated and I have never worked with Marlin or compiled Visual Studio code ever. With all that said, I carefully followed Sebazzz's guide posted above in combination with the one line of code to change provided by @ritchiedc, compiled the code, found the compiled .bin file, flashed it to the Motherboard following the Community upgrade instructions and VOILA it WORKED! Error message is gone, screen is working great (LOVE the new interface) and I am finally back to printing as we speak! So if you are reading this and think you can't do the manual compile, thanks to these great folks you absolutely can!!

In addition, I went ahead and did the 5V fix for the RaspberryPi and now everything is working perfectly

[vic131313]

Hi i have been having this exact same issue with the screen type mismatch 66116

I have enjoyed 2 years of great printing on the stock firmware but needed to calibrate my esteps and decieded it was time to go for the comunity firmware

I have tried 5 different sd cards (even bought a new one) multiple versions of the comunity firmware and the 2 versions of dgus2. and folllowed the readme file precisly. Each time i flash the tft i get all the correct lines appering on the screen as if i has done sucessfully, i have flashed multiple time (even trying upto 10 times) to ensure files have flashed correctly.

when i try to use the tft everything seems fine until i goto the bed leveling and click any of the otions there then the screen becomes unresponsive completly. if i select level the bed the hotend move to the center of the bed and raises about 25mm and starts heating along with the bed but nothing else happens past this point

i have tried going back to stock firmware but this just results in an unresponsive display that does nothing i wouldnt even care about the chinese writing if it worked but it doesnt.

only once have i not had the mismatch error, i flashed the 6.0 firmware and was actually shocked that i hadnt heard the annoying beeps of death, i managed to level the bed and for the first time ever saw the bed mesh. i quickly put it all back together thinking it had worked and prepared to settlle for ver6.0 over a not working printer but once i turned it back on again it beeped and gave the error again :(.

i tried the above work around for recompiling and changing the line of code for the screen test, it compiled fine and flashed fine but im still stuck with the unresponsive screen once i press any option on the bed leveling screen.

i have searched this probelm on google and keep getting the same small amount of pages which havent helped me so far.

im now thinking that i have a defective eeprom on my tft that just wont flash or instantly corupts the firmware after booting.

does anyone have any other suggestions as to fix this i would setle for almost any firmware at this point as i just have an expensive paperweight sat on my desk now.

Im now investigating Klipper as an alternative as i have several Pi's lying around and a working printer is what i really need but would really like the ftf to work again.

any links to either BTT MBs and TFTs avalible in the uk would be good as im not really sure which ones to go for or if i can even afford it atm.

again any help or suggestions would be greatly apprecieated as ive been banging my head against a wall for too long now

[Thinkersbluff]

This is not a display firmware issue.
It is the motherboard firmware which performs this test, and there appears to be a hardware issue preventing some systems from reading the DWIN_SET identifier variable correctly.

The motherboard firmware code line change suggested by ritchiedc above will bypass the test routine, for those who encounter this issue.