The Problem:

I have a ​Creality Ender-3 Pro that came with a 32bit 4.2.2 motherboard. The firmware on these boards can be updated by booting from a correctly prepared uSD card containing compatible firmware. (This is done by "the bootloader", which I will refer to as the "second-stage bootloader" hereafter because there is a first-stage bootloader in ROM which jumps to the second-stage bootloader at the beginning of flash, which in turn handles any firmware upgrade and then jumps to the firmware later in the flash. Being pedantically precise is important when dealing with machines at this low level.)

But if something goes wrong with a firmware upgrade, you can be faced with a device that shows only a blank screen, and very little to go on when trying to diagnose why it won't flash a correct firmware.

If the board does not attempt to flash, and boots into the existing working firmware, you should see the splash screen about 2 seconds after power is applied. If the board successfully flashes the updated firmware, you should see a blank screen for about 15 seconds, and then the splash screen of the new firmware. If the board does not attempt to flash and the existing firmware is broken, you will see a blank screen forever. If the board flashes a broken firmware, you will also see a blank screen forever.

I'm not the only one who ran into this issue, and I found a lot of advice online regarding this, but the second-stage bootloader on this board seems to be rather finicky, which led to people drawing apparently erroneous conclusions about what they did to fix their machines.

The documentation mentions that you should use a uSD card 8GB or smaller. But I have found that a properly-prepared 512MB uSD card does not work either. So it appears that there is also a lower bound to the uSD card size somewhere between 8GB and 512MB.

It is commonly believed that the firmware file must be named firmware<number>.bin, where <number> is a number different from what was previously flashed. I found that the requirement is that the file be named <something>.bin, where <something> is different from what was previously flashed. For example, I was able flash the firmware from a file named Ender-3 Pro- Marlin2.0.1 - V1.0.1 - TMC2225 - English.bin

And to be explicit, it only tracks the most recently flashed filename. If you have two uSD cards, one with firmware1.bin and the other with firmware2.bin, you can boot from them alternately, and successfully re-flash each time.

I have also seen people suggest using an 8.3 filename (limiting oneself to 8 character filename and 3 character bin extension). However, the firmware correctly identified that Ender-3 Pro- Marlin2.0.1 - V1.0.1 - TMC2225 - English2.bin differed from Ender-3 Pro- Marlin2.0.1 - V1.0.1 - TMC2225 - English.bin and flashed the image.

I found people talking about using a freshly formatted or brand new uSD card, and frequently people blamed cheap uSD cards as being faulty, including the uSD card that came with the printer. It appears to me that this is misattributing to the uSD hardware what is really a problem with the second-stage bootloader. Starting with an 8GB uSD card containing a correct firmware file, I would wind up with a blank screen. Taking that same 8GB uSD card, wiping the entirety of it with zeros, creating a vfat filesystem on it, copying that same firmware file to it, and flashing from that would reliably succeed. Writing an image of the previous filesystem to the uSD card would reliably recreate the blank screen problem. So the problem was clearly with the data, not with the hardware.

It appears that the history of the filesystem must play a role in the blank screen problem. The original uSD card, with all files deleted, and a correct firmware file copied to it, was causing the blank screen problem. I must conclude that the second-stage bootloader is looking at deleted file entries, or the data blocks for the firmware file were fragmented in some way that confused it, or... something. My attempts to produce a filesystem from scratch that would exhibit this behavior were not successful.

I've seen instructions about having to create a partition on the uSD card at exactly the right place. However, I found I could reliably flash the board with no partitioning of the device.

Solution

At this point, I can reliably flash the board with this process:

Fully wipe and format the device by running these commands as root:

dd if=/dev/zero bs=1G of=/dev/mmcblk0
mkfs -t vfat /dev/mmcblk0
sync

Caution: Ensure that you use the correct device name for your system (/dev/mmcblk0 was the device on my machine); using the wrong device could wipe and reformat your entire laptop.

When using the SD card slot on my laptop, the sync was superfluous, but when using a USB uSD card adapter, it would aggressively cache the writes and the bulk of the time was spent waiting on the sync. (That process takes about 12 minutes on my machine with the uSD card that shipped with the printer.)

Mount the device, then copy the firmware file to it as firmware1.bin, unmount the device. Insert it into the board, power on, and wait for it to flash and boot into the new firmware. If it does not attempt to flash, rename the firmware file and try again.

Caveats:

While debugging this, I attempted many scenarios with various parts of the system disconnected, such as all the motors, switches, sensors, and heaters. In order to get a handle on the variables, I did my testing to draw the conclusions in this article with the motherboard connected to the LCD screen, all other components disconnected, and powered by the micro USB port. I did verify that I was able to flash the firmware with the LCD screen disconnected; i.e., with the only connection to the board being the micro USB cable to power it. I did not see any indication that the board behaved differently with everything disconnected vs with everything properly connected and installed in the printer. But with the number of flaky oddities I saw in working through this, such context is important to capture.

I have upgraded my Ender-3 Pro with the ​4.2.7 silent motherboard, and ran into the same blank screen problem when trying to flash it to support the ​CR Touch. I was able to recover it using the same techniques above.