Unbrick TL-MR3040

Found a lot of helpful documentation and followed it: Bought an FTDI connector. Soldered three wires. Managed to speak to my bricked router, doing the tpl using a fresh Putty install on my Win 10 pro 64bit. I can do help or printenv even setenv serverip ... and I get meaningful responses.

At first I got many extraterrestrial characters in the console and noticed Putty was set to UTF-8 even for serial by default. I could not find any documentation what character set is needed for this mobile router, so I guessed Win1252 (Western). Now I can read all the text fine.

Managed to set up OpenTFTP Server and test it via localhost. Works at least locally.

Did printenv and found my TM-MR3040 is expecting the server to be at and set my TFTP Server accordingly (port defaults to :69).

Here https://openwrt.org/toh/tp-link/tl-mr3040#serial_console the documentation is giving as the server address, this is why I mention it. My router has got a lable inside saying:

TL-MR3040 Ver:2.5
2BG5399003320   3FB-4

Now when I do tftpboot 0x81000000 fw_s.bin (I renamed the firmware, got sick of the long names) router does make many attempts to pull from my server but nothing happens. Server log is not showing any communications. I get many T T T (for timeout I suppose). I found a very well done YouTube show and tell here:
And that guy also got many T T T. He then turned off his firewall (mine popped up and I allowed the traffic). And he suspected a "bad network cable" and used another. I have only got good quality cables and I tried several ones, just to be sure. I also tried a cross-over cable in case "bad cable" was not meant physically but "orientation wise". No joy. My network lights next to the plug on my computer are flashing, so there seems to be a good electrical connection. How can I test whether the router is even reaching my computer please?

This is what I get (for hours) typically:

hornet> tftpboot 0x81000000 fw_s.img

Using eth1 device
TFTP from server; our IP address is 192a168.1.111
Filename 'fw_s.img'.
Load address: 0x81000000
Loading: *T T T T 

You might notice a "bad character" (a instead of . in the ip address), I get a few of those randomly, so I suspect my soldering of GND is bad. My flux is too old I believe. If I make more attempts on this tiny eye, it will burn even worse.

So is there another well accessible GND-location on the router board which will give me a working serial connection? Can I for example use the nice and big outer metal casing on the large USB-connector? Or is the GND (pin 3) on this "serial set of pins" something special?

Otherwise is there a way to reduce the baudrate and let my Putty know about it. Maybe with a much reduced rate, I get a better connection.

Any other ideas or input are muchly welcome. Thank you. This is my first question here. Please correct, if I got something wrong, please do not hate.

In some cases you use the WAN port on the router instead of the LAN port. Or only one of the LAN ports will work. So try all the ports.

You should have a direct connection from the router to the PC, even better is to use a basic Ethernet switch so that the PC does not lose Ethernet carrier and reconfigure the port while the router is booting. Do not have it part of a larger network.

Make sure all firewalls are turned off. The only network connection on the PC should be to the router being debricked. Turn off the usual connection to the Internet.

A bad serial cable is an issue but it won't cause what you are seeing. You can use any of the ground plane on the router as your ground. I generally don't bother to solder the pins any more, just get a bonded set of 3 pins that are long enough to put in the sockets on the cable and go through the holes in the router. Then pull the cable to the side so the pins firmly touch the sides of the holes and hold it in that place during the procedure.

1 Like

Hihi, the MR3040 is a mobile router with only one LAN port! So that one better should work. I can see in my console references to eth0 and eth1 but none of the documentation has ever mentioned a need to solder any LAN stuff, so I assume the normal accessible and pluggable LAN-port is fine

Yes, I did most of that. Your hint to use a switch is helpful, I had seen many network-changes in my first set of TFTP logs, so I can improve that detail.

This is the juicy bit of your replay, thank you. I have put those pin-strips on my shopping list but got none in the house. Documentation wants the battery in place during procedures, so I got only one or two millimeters between the PCB and the battery. I like your trick to just create a make-shift plug and canter it laterally for good connection; will try it on my next router. For this one, I will not unsolder TX and RX as it was too hard to get it done.

I thank you especially for confirming that there is no "separate ground" for serial com purposes. So I will have more options to make more solder mess.

Shouldn't it be "fw_s.bin"?

1 Like


Hey forum, sweet success this morning, so I owe you the story:

We are on holiday, so tinkering. I was encouraged by @mk24 when he shared about "just plugging in" not even soldering. Also I had read more stuff about modern systems and lead-free soldering and basically I concluded "if you need more heat, you shall get more heat, I got not much to loose". Also I had the idea to use rather aggressive nail-polish-remover from my wife to remove all the gunk from my previous soldering attempts.

So today I got a better connection via serial. Still many bad characters, but I figured that the firmware will come via the network-connection, so as long as I mange to pass the tftpboo command and to reach my TFTP-server, I might get lucky.

So I did just some cleaning and a rather brutal solder with my bigger 30W iron straight into the serial-pin-3 hole on the router.

Then I downloaded the documentation for U-boot and took several shortcuts:

  • I never changed my computer-network setup today, kept my normal connection to the network, kept the home-router going...
  • just did setenv ipaddr to give the patient a valid number
  • then did setevn serverip to point to my Opentftp server
  • did nothing new to my Firewall since when I first tried this a few days ago, I had permitted Opentftp already

And today it just worked!! Cannot believe it. Got my router unbricked and learnt a lot in the process (had run a LibraryBox on it and came to you guys of OpenWrt to unbrick, when the instructions at www.librarybox.us were too unclear to go back to normal router operation; the LibraryBox as such did work fine on this router, but the population was not too enthousiastic to pull documents this way).


Also I found it awesome to see in my Putty console what the router was doing during a normal reboot, after setting my personal preferences. I guess I have to cut my cables before I can close the case. But this was a good experience.


This is not a legally valid proof photo, but it shows you that it worked. Thanks a lot to this forum and to the amazing work of the entire OpenWrt Project.