[SOLVED] Asus RT-N16 Bricked because unplug during flashing

[clickbait1]

A soldering iron (massive enough and hot enough) in one hand and a wooden toothpick or a sharpened match in the other hand will do the job.
A sharp eye and a steady hand are required too.

Yeah I just learned that yesterday. I crank up the soldering iron to 400°C and the solder just won't melt. I finally managed to make a through hole by using a small awl, then I clean the remaining solder with the 400°C soldering iron.

 

[mstombs]

Use new lead solder to wet old then pick up both with solder wick/sucker - or find an old solderer with the right rework station tools and skill to do the job (BTDTGTTS).

For capacitor replacement a possible technique is to destroy the cap using pliers then solder replacement to the legs.

 

[clickbait1]

Use new lead solder to wet old then pick up both with solder wick/sucker - or find an old solderer with the right rework station tools and skill to do the job (BTDTGTTS).

For capacitor replacement a possible technique is to destroy the cap using pliers then solder replacement to the legs.

I wish I knew this tip yesterday. But definitely will remember this for the capacitor replacement.

Trouble with Arduino and RPi is that the router specific software tools can't be used - another success story here, and a definite nvram clkfreq cause

http://www.dd-wrt.com/phpBB2/viewtopic.php?t=167165&postdays=0&postorder=asc&start=15

thanks for the link. My RPi+tjtag (v3.0.1) setup failed to probe the Flash type on the router. I was too tired to try out different flags/arguments, I figure I'm gonna put this aside for now and replace the capacitor and hoping serial recovery will be back.

I've only ever used a poor-mans parallel port plus resistor JTAG cable on other routers, usually from Linux because I could compile the older opensource versions of tjtag, the later versions of tjtag do not have public source code, leaving others to discover some Broadcom custom LV mode switches.

The older version of tjtag (particularly 3.0.1), does it work with RT-N16? The flash type (MX29GL256) is not included in the configuration. Is that why it fails to probe my flash?

OpenOCD can be used on the Raspberry PI and apparently can be used with RT-N16 and N66 (I recall the latter needs an extra resistor)
http://sourceforge.net/p/openocd/ma.../20131230192130.48983242CC@openocd.zylin.com/
https://github.com/synthetos/PiOCD/wiki/Using-a-Raspberry-Pi-as-a-JTAG-Dongle

thank you for the links, will look into that!

For a one-off exercise on an N16 consider just soldering in a few solid copper cat5 cables rather than a whole connector, clearing solder from ground plane holes is tricky. Cut the cables off when finished!

Already installed 12 pin header there

 

[mstombs]

I am pretty sure you need the non open-source tjtag 3.02 for N-16, the processor needs to have some custom commands to put it into standard ejtag mode. We were trying to get this into zJTAG, but that project seems stalled. Can the PI or Arduino work with the later tjtag binaries?

 

[clickbait1]

IT WORKS!

it turned out my CFE is (somehow) corrupt because of doing power cycle too early.

I used Raspberry Pi and OpenOCD (BIG thanks to mstombs who point me to that direction!). OpenOCD even comes with script to restore firmware on Asus RT-N16 and RT-N66U, made the whole process easier!

I thought I'd share the process for future reader:

What I did before this happens:
- With asus firmware restoration utility, flashed Tomato
- Didn't give enough time after "flashing" finished (for it to build nvram etc.), I unplug the power (power cycle).
- then symptoms below happen

Symptoms:
- No power light at all
- Upon power up, all LAN lights up, then the connected ones stays on
- can't ping (host unreachable)
- Serial console gives nothing (from linux: "screen /dev/ttyUSB0 115200")

Raspberry Pi JTAG setup:
RPi pin header reference

RPi Pin Header -- JTAG Pin
20 -- GND
19 -- TDI
21 -- TDO
22 -- TMS
23 -- TCK
18 -- SRST --> this one I forgot to plug in but it turned out just fine LOL

I use 100 Ohm resistor for all except GND.

Installing OpenOCD on Raspberry Pi (this one for v0.9)
Reference

sudo apt-get update
sudo apt-get install -y git autoconf libtool libftdi-dev libusb-1.0-0-dev
mkdir -p ~/src; cd ~/src
git clone --recursive git://git.code.sf.net/p/openocd/code openocd-git
cd openocd-git
./bootstrap && \
./configure --enable-sysfsgpio \
--enable-maintainer-mode \
--disable-werror \
--enable-ftdi \
--enable-ep93xx \
--enable-at91rm9200 \
--enable-usbprog \
--enable-presto_libftdi \
--enable-jlink \
--enable-vsllink \
--enable-rlink \
--enable-arm-jtag-ew \
--enable-dummy \
--enable-buspirate \
--enable-ulink \
--enable-usb_blaster_libftdi \
--prefix=/usr \
&&
make

The configuring part takes ca. 5 mins. and compiling takes definitely more than 30 minutes (I went to bed and left it overnight). Ignore the missing makeinfo error/warning. Not sure whether all these configurations are necessary, but I did it anyway. After compilation finished, do "sudo make install"

What I did with OpenOCD
- backup the CFE twice

cd /usr/share/openocd/scripts; sudo openocd -f interface/sysfsgpio-raspberrypi.cfg -f tools/firmware-recovery.tcl -c "board asus-rt-n16; dump_part CFE /path/to/your/home/cfe.0.bin; shutdown"

- compare the binaries (use "cmp -l cfe.0.bin cfe.1.bin", or md5sum). if they're not identical, something is wrong with JTAG setup
- download the working CFE here
- erase nvram and flash working CFE (takes 30mins with 0.4KiB/s)

sudo openocd -f interface/sysfsgpio-raspberrypi.cfg -f tools/firmware-recovery.tcl -c "board asus-rt-n16; erase_part nvram; flash_part CFE /path/to/the/working/cfe.bin; shutdown"

- power cycle
- serial console is now working again, as well as TFTP server also the power light

this is awesome! I really appreciate the help guys!

by the way I didn't change the capacitor.

 

[clickbait1]

I am pretty sure you need the non open-source tjtag 3.02 for N-16, the processor needs to have some custom commands to put it into standard ejtag mode. We were trying to get this into zJTAG, but that project seems stalled. Can the PI or Arduino work with the later tjtag binaries?

Yes I thought the same, tjtag 3.0.1 doesn't support RT-N16 yet. Not sure if tjtag 3.0.2 will work with RPi because the source needs to be patched with the bit-banging routines.

 

[mstombs]

IT WORKS!

Congratulations! Don't you have to hexedit your device specific mac addresses into the CFE?

 

[clickbait1]

Congratulations! Don't you have to hexedit your device specific mac addresses into the CFE?

hmm is the MAC address hardcoded to the CFE?

 

[mstombs]

The CFE contains a default NVRAM set with device specific MAC addresses for the various interfaces. Often folk posting to dd-wrt forums blank them or replace with XX, the one you linked to didn't. Use Linux tool "strings <filename>' to see all the text in the CFE - interesting it suggests the CFE does nafe the "Mini Web Console". If you did not change them your router you now have a clone of that one. Some CFE need to have a checksum amended if contents of CFE changed by hand using a hexeditor, there are various tools around to do this if needed. BUT easiest/safest now would be to write a script with "nvram set" commands. and remember to use if needed in future. There is usually just one MAC address on a label on the router, others are an offset away.

 

[gatorback]

It was necessary to replace the RT-N16 capacitor in both my devices. At the time, I was fortunate because I had a senior EE with a study hand and the right lab equipment.

 

[clickbait1]

It was necessary to replace the RT-N16 capacitor in both my devices. At the time, I was fortunate because I had a senior EE with a study hand and the right lab equipment.

thanks for the reply. it turned out my capacitors are fine. fixed it with JTAG.

The CFE contains a default NVRAM set with device specific MAC addresses for the various interfaces. Often folk posting to dd-wrt forums blank them or replace with XX, the one you linked to didn't. Use Linux tool "strings <filename>' to see all the text in the CFE - interesting it suggests the CFE does nafe the "Mini Web Console". If you did not change them your router you now have a clone of that one. Some CFE need to have a checksum amended if contents of CFE changed by hand using a hexeditor, there are various tools around to do this if needed. BUT easiest/safest now would be to write a script with "nvram set" commands. and remember to use if needed in future. There is usually just one MAC address on a label on the router, others are an offset away.

I randomize my MAC address upon router boot, so problem solved?