OpenWrt Forum Archive

Topic: Archer C7 Serial Port Mod - Need Help

The content of this topic has been archived on 21 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

So I'm trying to add a serial port connector to my C7 but I can't get it to show me anything. A few days ago I transplanted a 3 pin header from another circuit board to use in the C7 along with serial cable that I found for my raspberry pi. After soldering in the pin headers and connecting it, I found out first the cable had a fake FTDI chip in it and secondly it just flat out doesn't work in Windows 10. After re-assembling the router I found out that while it turns on and the power, star, 2.4 & 5 GHz, ethernet jack and WPS lights come on (no internet since I was using it as a WAP), it wasn't broadcasting SSIDs nor could I access it via it's IP. I also couldn't recover it via TFTP (edit: It doesn't even boot into recovery mode, it just ignores the button and boots up normally, I sniffed the packets). It was sending and (trying to) receiving packets though since there was activity with the LAN light. I just tried it again now (a few days later), using it as a switch and it works perfectly, so there's nothing wrong with it which is great, but I can't access LuCI or SSH via the IP I had assigned to it before all of this happened. edit:  I ran a portscan of the 192.168.1.0 subnet and didn't find any IP registered to the C7, the WiFi doesn't work, yet it works perfectly as a switch.

I bought a MicroUSB to Serial Breakout - FT232RL and soldered the Tx, Rx and Ground wires from the FTDI to the pads on the C7; connected the USB cable to my PC and let it install the drivers, then opened up PuTTY and connected to COM7; then I connected the power cable to the router and pressed the power button, all the lights came on but there wasn't any output from the console....

Thinking maybe I made a bad joint, I tested the continuity from each pin on the FTDI with the corresponding pin on the C7 and each one rang out! Then just to make sure that I wasn't shorting any pins, I tested the continuity between the Tx and RX pins on both the FTDI and the C7 and they were quiet. I did the same between Rx and Ground and it was quiet also. I repeated this with Tx and Ground and it rung out on both ends!

Now I'm not that great with electrical work (my dad is an electrician so I know a little bit), but is there supposed to be continuity between Tx and Ground (Pins 1 & 3), and not between Rx and Ground (2 & 3)? Also while the board was powered on and the FTDI was connected to my PC I decided to check the voltages and I got 2.121v DC for the Tx and 3.310v DC on the Rx, something tells me the Tx should be 3.3v also shouldn't it?

On a side note, I also have the JTAG pin headers soldered in, in case it helps with debugging WTF is going on.

(Last edited by brando56894 on 20 Mar 2016, 01:19)

I seem to be having the same results that you are. I am using a 3.3v configured FTDI FT230X and a 3.3v configured CP2102 UART chips

Neither have worked. Both have the same result, when the chips are powered (and the devices recognized by the computer) the C7 refuses to boot. It shows the first four LEDs from the left as being on, and the WPS LED all the way on the right-side. Nothing is outputted to the console.

I've pretty much reached my limit of understanding, I can only assume that it's checking for voltage on one of those pins and that is causing it to not boot on purpose.

Interesting that we both have the same result. Were you on Chaos Calmer as well?

I haven't been able to successfully boot OpenWRT yet. I have one of the post-Jan 2016 unmarked revisions that not only prevents flashing OpenWRT via the WebUI (header checking) but also is doing something else that prevents it from booting OpenWRT. (hence my attaching a serial header and doing this)

I was hoping to get some output, but no dice.

Works with both chips now. Sorry for the confusion.

Interesting! I thought I had already tried switching the leads, but I'll give it a try again. Thanks for the heads up!

Edit: I swapped the leads and it looked promising at first since both LEDs light up when I connected the USB cable instead of just one, but still nothing from Putty. I'm going to boot into Linux and try it from there.

(Last edited by brando56894 on 21 Mar 2016, 22:27)

The following boot logs are from an Archer C7 mfd. on 1/11/2016:

Stock booting latest US firmware: http://paste.fedoraproject.org/343500/95075145

Flashing CC over TFTP: http://paste.fedoraproject.org/343507/95997145

Booting just CC 15.05.1: http://paste.fedoraproject.org/343506/45859571

[    2.100000] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[    2.100000] Please append a correct "root=" boot option; here are the available partitions:
[    2.110000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    2.110000] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

that seems to be why I can't boot CC

(Last edited by xenith on 21 Mar 2016, 22:33)

Re: PuTTY, I did it on minicom on linux

My UART chips come up as /dev/ttyUSB0, so

sudo minicom -8 -b 115200 -D /dev/ttyUSB0 -C <capture> 

where capture is optional, works for me.

Actually, this doesn't look so bad. Not an encrypted/signed lockdown scenario, just a relatively trivial hardware substitution by TP-Link. The MTD driver isn't recognising the (new type?) SPI flash chip and hence the kernel can't mount root.

This commit to the kernel in early 2015 added your particular device (JEDEC id c84018) https://git.kernel.org/cgit/linux/kerne … a98bf577d8

I'm not sure if it's the OpenWRT kernel or the OpenWRT device tree for the Archer C7 that would need to be updated to accommodate this.

I just tried minicom also and got the same result (nothing). Just for the hell of it, I'm going to remove the pins and solder the leads directly to the pads, to rule out the possibility of any bad connections.

@dspalu32

I think I've learned my lesson to try trunk builds first, as that actually works.

Once we figured out that it was the flash chip not being recognized, and that support had already been committed, it was obvious that's what needed testing next.

Since I'm new to OpenWRT, a release that came out 5 days ago didn't strike me as something that would be that out of date, but indeed it is.

I can report now that the Archer C7 w/ the new flash chip works on the trunk (dev) build.

After swapping the leads around I'm getting 3.3v on both Rx and Tx and there is no longer continuity between pins one and three. I think there may be something up with my ground because when I wiggle the wire sometimes it makes odd characters like a diamond with a question mark inside:

`� ��`d`pPq�!���Р03�f�&�,ВI�                    �       ��$��2xK9�@PA���*h4�/��

The problem is that I seem to have a pin header stuck in the hole, so I scraped off a little of the green coating to expose the metal close to the pad and soldered it there. Still nothing though :-/

Trunk build works. Thanks guys.

Brando, just to cover the easy stuff, you are keeping in mind that tx from the router goes to rx on your usb serial device, correct?

Totally didn't realize that, but it makes complete sense, I was trying to figure out the sender/receiver the way I had it hooked up and it just didn't make sense, that should have been my first clue. I reversed the Rx and Tx wires on the FTDI side and...... nothing.

Warning Graphic Pictures Ahead (Hahaha)

Underside of the board, Ground connection
http://thumbnails114.imagebam.com/47309/9182c3473089028.jpg

top of the board Rx (Top, Yellow) and Tx (Bottom, Blue) connections
http://thumbnails114.imagebam.com/47309/c179b1473089030.jpg

The FTDI Chip
http://thumbnails113.imagebam.com/47309/0236b0473089441.jpg

The router PCB looks a little worse for wear because the soldering iron I had started with originally was old and had a pretty blunt tip. So when I ordered the chip and the other stuff I ordered another iron, which had a really pointy tip, which works a lot better.

(Last edited by brando56894 on 22 Mar 2016, 03:07)

Also try different serial bitrate. I had experienced something similar before and the reason I get those symbols is due to me setting the wrong bitrate.

Any suggestions? I don't feel like going through all 15 or so bitrates lol

brando56894 wrote:

Any suggestions? I don't feel like going through all 15 or so bitrates lol

Use the bitrate on your router wiki page or try the common ones until you get something you can read.

Minicom only supports 3 speeds: 9600, 38400, and 115200. I tried all three and still got nothing.... The recommendation on the wiki page is 115200.

It should be 115200 8n1.  Make sure hardware flow control is disabled, too.

You could continuance test your work to make sure you didn't accidentally break the traces or solder bridge something.

Yep, that's what it's set to. I already did continuity and voltage testing and everything looks ok. Is there any place on the board (other than the pads) where I can check the circuits for continutiy from the FTDI to somewhere past the pads to make sure the whole circuit is ok?

spanky wrote:

Trunk build works. Thanks guys.

xenith/spanky - did you have to TFTP an old version or flash DD-WRT first before the trunk would flash and boot for you? I'm still getting an 'Error 18005' still when trying to flash OpenWrt from my current stock Archer firmware, even with a shorter filename.

Thanks!

The discussion might have continued from here.