A few words about serial console recovery for OpenWRT: technically speaking each router has a serial port. OpenWRT on TP-LINK MR4320 and MOST IMPORTANT how to use it because I made the cable, I connected myself, it was working, but I had no clue how to perform the recovery, I am not familiar with Unix / Linux.
→ So in contrast to the, the Serial Ports needs some software running on the CPU so we can use it! In case the bootloader is damaged, or does not offer such a feature, the port is useless.
Finding an UART on a router is fairly easy since it only needs 3 signals (without modem signaling) to work: GND, TX and RX (often accompanied by VCC). Since your router is very likely to have its I/O pins working at 3.3V ( level voltage), you will need a level shifter such as a Maxim MAX232 to change the level from 3.3V to your computer level which is usually at 12V. To find out the serial console pins on the PCB, you will be looking for a populated or unpopulated 4-pin header, which can be far from the SoC (signals are relatively slow) and usually with tracks on the top or bottom layer of the PCB, and connected to the TX and RX. Once found, you can easily check where is GND, which is connected to the same ground layer than the power connector. VCC should be fixed at 3.3V and connected to the supply layer, TX is also at 3.3V level but using a multimeter as an ohm-meter and showing an infinite value between TX and VCC pins will tell you about them being different signals (or not). RX and GND are by default at 0V, so using the same technique you can determine the remaining pins like this. If you do not have a multimeter a simple trick that usually works is using a speaker or a LED to determine the 3.3V signals.
Additionally most PCB designer will draw a square pad to indicate ping number 1. Once found, just interface your level shifter with the device and the serial port on the PC on the other side. Most common baud rates for the off-the-shelf devices are 9600, 38400 and 115200 with 8-bits data, no parity, 1-bit stop. Cleanup Required! This page or section needs cleanup.
You can this page to fix wiki markup, redundant content or outdated information. Many people get along without a serial console for their device because they are able to flash working firmware the first time or are able to apply various recovery methods and do all their communicating with the device over a network. However, due to characteristics of their bootloaders or because they are not yet fully supported, for some devices it can be quite handy to have a compatible serial console available. Most devices that are supported by OpenWrt include a serial port. These serial ports typically provide a console to the bootloader and, when the firmware has booted, a console to the running system. Typically, a console to the bootloader will allow you to configure a network, fetch and flash a new firmware, which can be a life-saver when the firmware is broken. A console to the running system will let you correct a misconfigured network.
This section descripes actions that might damage your device or firmware. Proceed with care! Caution: Very few devices have standard +/- 12V serial ports, but in many OpenWrt-supported devices the serial ports operate at TTL voltage (sometimes 5V, most often 3.3V) levels, meaning you cannot use a standard serial or USB to serial cable: it will fry your board.
In order for the serial console to work, the logic levels on the wires should match those expected by your device. The first step therefore is to determine which voltage levels are required. Often, you can find this documented on the OpenWrt wiki or elsewhere. Check your device's voltage levels with this chart. For detailed description look In addition these levels are averages for the type of devices shown. In order to interact with your device over its serial port, you need a minimum of three wires connected: a ground (GND); transmit (TX); and receive (RX).
It is possible to get useful information about what is happening with only GND and RX, but in order to fix a problem you will usually also need TX. Your computer's TX should be connected to the device's RX, and your computer's RX should be connected to the device's TX. The computer's GND should connect the the device's GND. That way, what you say will get heard by the device and what the device says will get heard by your computer. This is often called a 'null-modem' configuration. You will also need a terminal emulation program on your computer, such as minicom, hyperterminal, etc. The terminal emulation program needs to be configured to be compatible with your device, in particular, with regard to baud rate and flow control.
If you are using only three wires (GND, TX, and RX) then hardware flow control should be turned off; you aren't using the pins (RTS and CTS) necessary for it to work. Rarely, the baud rate that the device expects might be different in the bootloader and the running firmware; if so, you'll need to modify the baud rate settings in your terminal emulator after the firmware boots up.
First, you need an 'RS232-TTL level converter chip.' RS232 refers to the standard defining what plugs into your computer, and TTL is a family of chips that use 0V and 0.8V as low and 2.2V and 5V as high. They can be purchased new (the MAX233x line is popular). Most vendors have large minimums, but some (e.g.
) sell components in small quantities. The wiring is fairly simple, but it depends on the chip.
Linux Serial Port Programming Example
Generally, it involves connecting Vcc from the router to the chip's Vcc pin, both router and rs-232 grounds to the ground pin, and the TX and RX wires to the chip. Remember that the router's TX will 'connect' to the same level conversion bank as the computer's RX. Additionally, some of these level converters require external capacitors, while some have them built in. Much of this varies, so consult the chip's spec. Another great source for RS232-TTL converters is in cell phone serial cables. Most cell phones need this same circuit to level-up for connection to a PC's serial port. Many people already have such a cable laying around, or can buy one fairly cheap.
Using an existing cable is much easier than building one. If you open up the cell phone cable's serial port casing and see a MAX### chip, it's probably the cable you need. One known chip is a MAX323 (yes, 323, the original MAX232 is a 5V device and we need 3.3V here). If you've found a good cell phone cable to use, you merely need to determine which wires are the VCC, GND, TX, and RX connections. Usually the VCC is red and the GND is black, but the other colors may vary (though blue and orange are common). There should be no need to modify the PCB embedded in the cable.
One type of the 'Made in China' ones, not mentioned at ist the 'S30880-S5601-A802-1'; its WHITE wire is data out (TX) and the ORANGE one is data in (RX), VCC and GND are red and black. Its a 3.3V converter built with the MAX3386E chip. This leaves two pins to identify: RXD and TXD. It's easiest to find the router's TXD pin first, because all the console output from the boot process appears there.
Connect the RXD pin of your level shifter to one of the remaining console pins and re-start the router. You should have a terminal window connected to the serial port at the correct bitrate and parity, and you've connected the proper pin, you should see output data the router's startup process. If not, try another pin, restarting the router until you receive valid output. Now you've located the serial port TXD connection.
So.I am using a serial device connected to a Keyspan Serial-to-USB adapter and plugged in to my computer's USB port. The device is constantly sending 115200 baud data over UART, with no parity, 8 data bits, 1 stop bit, no flow control, and no handshaking. I can read the data just fine on my Windows machine (once I install the Keyspan driver). On Arch64, I notice that when I plug it in, /dev/ttyUSB0 shows up so I believe that means the kernel is recognising the device and already has drivers to handle it. I would like to simply see the output of the device through my terminal emulator so I have written the following script. I have tried to make that work too before. But I did put it on hold (wasn't successful) but it would be great to know how to do it.
It would be very handy because it would allow me to get some printscreens from oscilloscopes with a serial port. At the time I did try to fiddle with stty, setserial, and either minicom or gtkterm (can't remember which one) but no luck there.
I remember stty and setserial had way too many options when compared with the simple setup windows and the oscilloscopes have. Thanks, all for the responses!
Perbh: I wasn't sure exactly how to implement your suggestion. If the cat line doesn't use the variable, '$LINE', how can 'echo $LINE' work? I am probably missing something simple. Well, I have had a little success. The following script creates blank lines whenever data comes in through the usb device. Basically the device sends FFT data whenever it hears a sound which is greater than a certain threshold, so when I snap my fingers near it I see the FFT data show up in Terminal on Windows.
Now, with the script below, if I snap my fingers my Linux machine outputs a bunch of blank lines so basically I just see my linux terminal emulator scrolling whenever I snap my fingers Does anyone have any ideas how to get the actual data on Linux? Thanks again! There must be a description somewhere of the data. It could be plain binary (in which case read/cat might not show up much, unless you use 'cat -v' (ie 'print' non-printing characters). It the data arrives as a string - it most probably is terminated by CR and LF.
However - untill we know what the data is like, its difficult to say which is the most correct way. I have had quite a lot of success with 'minicom' in the past. So - give us a brief description of the data and we'll see what we can do. When in 'cooked' mode (which is the default), you wont see anything until it finds a LF in the stream Instead of '-icanon' above, use '-cooked' But - as you have been told 2 or 3 times by now - try out 'minicom' first! If that works - ie at least you can 'see' some activity, then you can go on to something more adventurous edit Was busy checking 'man stty' and didnt see your last post. Basically, in 'minicom' what you need is 'ctrl/a - o' You just have to forget about all the modem-specific detail Other than that - doing a little bit of c-programming on a serial port is a no-brainer.
Hadise dum tek tek lyrics. Retrieved 2010-11-28. Archived from on 2010-12-13.
Linux Serial Port Programming
But personally - I alway use minicom/stty/cat first to make sure something is actually happening, then I go and tailormake it for my personal use. Last edited by perbh (2009-10-30 14:28:23).