Hi,

I have a TP-Link Archer C7 v2.0 and for some reason it refuses to boot properly. When I connect to its serial console and power it on, I see just a few lines of U-Boot and then the output stops:

U-Boot 1.1.4 (Dec 17 2013 - 16:37:27)

ap135 - Scorpion 1.0DRAM:  
sri
Scorpion 1.0
ath_ddr_initial_config(211): (32bit) ddr1 init

The boot process seems to be halted there and typing does not cause any characters to be printed back. However, sometimes when I power on the router with the WPS/Reset button pressed, I get slightly different output:

U-Boot 1.1.4 (Dec 17 2013 - 16:37:27)

ap135 - Scorpion 1.0DRAM:
sri
Scorpion 1.0
ath_ddr_initial_config(178): (32bit) ddr2 init
tap = 0x00000003
Tap (low, high) = (0x4, 0x1f)
Tap values = (0x11, 0x11, 0x11, 0x11)
128 MB

which looks more like a reference boot log from the device's wiki: https://wiki.openwrt.org/toh/tp-link/ar … c7-wdr7500. The output still stops at that point and I am still not able to get any characters printed back when I type.

What is worth noticing is that the line with

ath_ddr_initial_config

has changed. Instead of ddr1, it makes a reference to ddr2. The boot log at the device's wiki shows ddr2 as well. So, it looks like the DDR memory is sometimes initialized to ddr1 and sometimes to ddr2. It does not look right to me, but I have no experience or knowledge in the matter.

I assume the only way to debug and fix this is to use JTAG. I would welcome some advices on how to set it up properly. I have the following JTAG adapter:
http://www.aliexpress.com/item/Freeship … 85138.html
but it only has 10 pins (i.e. no nTRST, nSRST or DINT pins). Do you know if it would be possible to use it with the router's 14 pin EJTAG port? I have read some articles which mention the need for nSRST pin at some boot stage, because (supposedly) otherwise JTAG interface might not be working. But they were referring to different devices and I am not sure if the same or similar principle would apply here as well or not.

Anyway, I can get some other JTAG adapter if needed, but even if I had JTAG connection fully set up and working, what should I do then? My goal is "just" to make the router work again. I can use openocd or UrJTAG, but none seem to ship with the configuration files for the router's board. So, I would have to write it on my own, but I do not have experience in that. In fact, a few days ago I did not even know what JTAG is.

So, I would like to ask if someone has made a successful JTAG connection to this router's board. If yes, can you please describe your approach and share your settings?

Thank you.

This is probably the reason of your problem.

Qualcomm/Atheros U-Boot recognizes DDR memory type (DDR1/DDR2) using bootstrap register which value is setup based on selected GPIO states at power up (take a look here). Archer C7 is based on QCA955x SoC which uses GPIO10 for DDR_SELECT 1-bit field in RST_BOOTSTRAP register. Value 1 selects DDR1 (default), value 0 selects DDR2.

I suppose that you have some kind of short (dust, mess left after soldering process?) or damage (missing pull-down resistor?) somewhere on PCB which causes your problem. I have already seen similar problem with other TP-Link devices (selected wrong memory type, booting from wrong device type, etc.).

What I can recommend here is to try find GPIO10 signal on PCB as it must be pulled-down with some resistor for DDR2 selection and check if everything is ok with it. When the board boots fine, try to export GPIO10 as output in the system and search it using multimeter/scope (write some script which will change output state from 0 to 1 in loop).

GPIO10 is located in top right corner of the BGA package (last column, 7th row from top, XTAL inputs are located at the same column in 4th and 5th row):

From what I can see here it seems that GPIO10 signal goes to bottom layer of the board (but this is only my assumption, signal could also be router under the chip).

I don't think that JTAG will help you here as it seems to be a hardware issue.

Thanks pepe2k for the detailed analysis!

I have just seen a very similar snippet in the U-Boot source code that is part of the original TP-Link firmware for Archer C7 v2.0 (link) and assumed it works as you have described.

That is possible. But I cannot see any damage on the entire board. I did not do any soldering because I do not have tools or experience. I have only connected the serial console using jumper wires and I planned to do a similar thing with JTAG.

The router started behaving erratically just some time ago (spontaneous wifi disconnects, then spontaneous reboots) and eventually stopped booting completely. I have had it for almost 2 years and it worked fine all that time.

Well, this is kind of above my capabilities. I do not even have basic tools like multimeter. I might show the board to people at a local mobile phone repair shop. Maybe they would be able to help, but it will cost money and I am not sure if it is worth it.

Besides, I am not sure if I understand what exactly needs to be done. How can I e.g. "export GPIO10 as output in the system"? And more importantly, how to do that if the board does not even boot properly? Even if ddr2 is selected, the boot process still halts at U-Boot.

You are most probably right. But still, I think that if I can get JTAG to work, it might at least help me to confirm if the problem is indeed HW related or not.

Maybe it is relevant, maybe not, but I have tried to reboot the router multiple times and watched the serial output to see how it behaves. On top of the above mentioned boot logs, I managed to obtain another slightly different one:

U-Boot 1.1.4 (Dec 17 2013 - 16:37:27)

ap135 - Scorpion 1.0DRAM:  
sri
Scorpion 1.0
ath_ddr_initial_config(178): (32bit) ddr2 init
tap = 0x00000003
Tap (low, high) = (0x5, 0x1f)
Tap values = (0x12, 0x12, 0x12, 0x12)
128 MB

It does not seem to matter whether I have the WPS/Reset button pressed or not during the power on. I can get all kinds of boot logs mentioned here with roughly the same probability.

Notice that with the last boot log, the "Tap (low, high)" have changed and so have "Tap values" (from 0x11 to 0x12). I am not sure what that means, but it points to more nondeterminism that is happening when reading the relevant registers during the U-Boot phase. Whether it is caused by some short-circuit or something else I do not know, but it probably affects multiple registers (or other places used for decision making during U-Boot) and disallows it to successfully continue.

TAP values are not static and may slightly differ from one to another power up (final values are calculated as 1/2 of min and max sum).

If it was working before without any problems and started to behave like that after 2y then it could be some serious hardware problem with main SOC and/or DDR chips - maybe you need reballing.

I don't know how JTAG could help you here.

I did not know that - thanks for the insight.

That sounds like a good idea. But I am not able to do it myself and having it done by a professional electronics repair shop would probably cost enough to make it impractical.

Me neither. I just think it might help to confirm and locate the problem, not resolve it.

Anyway, I am also under strong impression that whatever I would be able to find out and confirm over JTAG, would not be easily fixable (by me). As a result, I now have a good reason to stop trying to make it work again.

But thanks pepe2k for all your insights and for trying to help. If I had (much) more experience with electronics and the suitable equipment, I would probably try your suggestions. But right now I stand here with literally my bare hands and a couple of jumper wires, which ... is just not enough.

Thanks again!