TP-Link Archer MR200(EU) V2.1 -- Bricking & Unbricking

Hi, Folks,

Truly thank to those who have contributed to the Wiki of Archer MR200 V1. I, however, would like to point out that there are two misleading information on the page. One is how to make a custom firmware, and the other is how to install the firmware.

As mentioned in the section of Make Custom Firmware, the outline of the process is to (1) cut off the header of TP-Link firmware, (2) extract the bootloader from the header-less TP-Link firmware, and (3) concatenate the extracted bootloader and the OpenWrt sysupgrade.bin to generate the recovery.bin which is recognisable by the router. After following the instruction to the letter, I reckon that the following commend of the 2nd step truncates the bootloader accidentally by 512 bytes.

dd bs=512 obs=512 skip=1 count=256 if=Firmware_NoHeader.bin of=MR200_Bootloader.bin

The correct one should be

dd bs=512 obs=512 count=256 if=Firmware_NoHeader.bin of=MR200_Bootloader.bin

Regarding OpenWrt installation, the misleading info is pretty minor. In the TFTP recovery mode, the router acts as a TFTP client rather than a TFTP server. Thus, the computer needs to be set up as a server to host the required recovery.bin.

The last thing I would like to share is how I forced the CH341A programmer to recognise the SPI flash (GD25Q64CSIG) of the bricked router via SOIC8 test clip without desoldering the flash from the board. Hopefully, it will be useful for folks who are in the pit.

During the journey of debricking the router by writing back the stock oem flash dump, I reckon it's next to impossible to get the flashrom programme (running on Debian x86-64 platform) to recognise the flash by repeatedly doing a series of actions including plugging in the programmer, launching the command and then unplugging the programmer. A workaround is to connect all the pins of flash to the programmer, except the Vcc pin. Then, plug the programmer into the USB port, launch the following script, and then connect the Vcc pin of the flash to the programmer.



while [ $unfound -eq 1 ];
	sudo flashrom -p ch341a_spi
sudo flashrom -p ch341a_spi -r dummy_dump.bin

The very first reading (dummy_dump.bin) is definitely wrong. But once the flash is recognised and the script exits, the subsequent readings will be identical.