Wrong version of firmware caused motherboard damage (?)

[magmabow]

###Description

E3V2 not booting after accidentally installing the wrong version. ive tried a few solutions however nothing seems to work. (unless im doing something wrong?)

Steps to Reproduce

1. download the wrong file: E3V2-ManualMesh-3x3-v4.2.7-v2.0.1to an sd card
2. place the sd card into a E3V2 4.2.2
3. boot 3d printer
4. realised its the wrong version after 3 minutes and rebooted printer with version 4.2.2
5. printer not booting and stuck

Expected behavior: [What you expect to happen]
E3V2 boots up normally

Actual behavior: [What actually happens]
E3V2 stuck where lcd is on a solid dark blue color, and the fan is running. other than that, nothing happens

Additional Information

[Ergonomicmike]

Well, first, this isn't really an Issue with the code, since you used the wrong firmware. So this is more of a Hardware Support question.

Having said that, on the assumption that the board didn't fry or lock up, the only thing I can think of, which you might know already, is that a new firmware bin with the same numbering as a previous firmware bin won't load.

It would be unbelievable that a build of a 4.2.2 bin would have the same numbering as a previous 4.2.7 bin, since it seems that the numbering uses Real Time in its scheme.

Anyway, easy enough to check. If the 4.2.2 bin number is the same as your 4.2.7, then simply rename the bin with a different number on the 4.2.2 bin and try flashing again.

Or you could try downloading a vanilla firmware from Creality's website and try that.

I once made a similar mistake with a computer motherboard and bricked it. The only solution there was to borrow an EPROM burner from a buddy of mine and reprogram the Flash memory of the board with the correct firmware. In those days, one could remove a discrete IC and put it in the burner. If you've hosed the flash memory, then I suspect that you will have to buy a new motherboard. You could upgrade to a 4.2.7.

[LCh-77]

4.2.7 board has a bootloader and cannot be overwritten by flashing the firmware using the SD card. So, use another card, format it to FAT32, 4096 bytes Allocation unit and rename the firmware file.

[classicrocker883]

@magmabow if u have an St link u can plug the board right into the computer. ull have to get st-link drivers. I actually had better success using vscode in Ubuntu /Linux. but it can work in any. so u may have to edit the .ini file. like stm32f1.ini and look for the environment you need. make sure the debug and upload protocol are set to stlink sometimes its jlink.

u may have to get a 4 pin header to plug into because my 427 doesn't have it. but anyway instead of build do upload and it should work. this is called a soft brick. it's not hard bricked. so there is a way to fix it if u haven't already.

[bellertm1]

4.2.7 board has a bootloader and cannot be overwritten by flashing the firmware using the SD card. So, use another card, format it to FAT32, 4096 bytes Allocation unit and rename the firmware file.

Same experience and eventual solution learned the hard way - in case it helps spawn ideas for a cheat sheet to assist with troubleshooting (and as a newbie, have found discords at the main Marlin Config branches helpful):

Issue: (assumes working hardware prior) Forgot to change BIN file name EVERY time and got same result after Jyers E3V2 (that uses nicer LCD - not green screen)

**Actions taken: ** discovered hidden feature with new 4.2.7 boards (not just GDF) on Marlin company specs site and Git discords:
*Even if re-flashing the same version, the file name must be different. This worked, but not consistently - discovered that screen firmware can get corrupted (easy fix - same as for machine with SD card formatted at 4096 and the appropriate screen firmware files). Additionally, found that the repeatable success went to 95% after downloading/compiling/flashing with base hex encoded files from marlin for 1.0 and then 2.0, along with DWIN, TFT, DGUS , etc screen files (**Please note, this probably wasn't necessary, but it helped ensure that all firmware releases were synchronized and it improved the success rate for Creality 4.2.7 board - unsure on other boards with bootloader/onboard flash memory installed .

Adhoc in-experienced solution: works 95% of last 20 flashes for Creality 4.2.7 with 2225 (AKA black computer board with Creality name and certificate as official lol along with OEM screen for that machine). Also noteworthy, there are continuing great updates in platformio that had to catch up - e.g. board - Creality_V4 and now is Creality V427 and saw how that impacted compiling the myriad of Creality boards).