Author Archives: martinjonestechnology

Raspberry Pi portable development system

I’m often away from my lab and need to carry on working, in airports, co-working offices, at customer premises and so on. Of course, I have a laptop, but that only goes so far when you’re working on embedded Linux hardware. I need to be able to take the hardware with me, and work with it.

Recently I’ve been doing some work with the Raspberry Pi. The Pi is normally set up so that you plug a monitor, keyboard and mouse into it and use it as a desktop computer. That’s OK, but inconvenient for travelling with. You can also log in to it over a network, but that’s not a great idea when I have no idea what networking facilities, if any, will be available where I’m working.

My preferred way of talking to embedded systems is old-fashioned: over a serial port. It may not be the fastest, but it’s reliable and need no infrastructure at all. The Raspberry Pi has a serial port on its GPIO connector, pins 8 and 10, and the standard Raspbian Linux distribution has it set up to be a console. That’s just what I want. Now I just needed a way to connect it to my laptop.

As luck would have it, FTDI make some handy USB-to-serial converter cables. The one I chose for this application is the TTL-232R-3V3. They’re available from various places, but I bought mine from Farnell, part number 1329311.

The connector on the FTDI cable has six pins. As delivered, they are

Black GND
Brown CTS
Red VCC
Orange TXD
Yellow RXD
Green RTS

The pins along the edge of the Raspberry Pi’s GPIO connector go:

2. +5V
4. +5V
6. 0V
8. TXD
10. RXD

Ooh! How convenient. The 5V power input is available next to the serial port. By rearranging the pins on the FTDI cable’s connector, it’s possible to make a cable which will both power the Raspberry Pi from USB and connect the console to the serial port. That’s perfect for mobile use. The cable is easy to modify: the pins are held in by little black plastic tabs which you can gently bend back with a jeweller’s screwdriver, tweezers or a scalpel. The modified cable is wired like this:

Red +5V
not connected
Black 0V
Yellow TXD
Orange RXD
not connected

The spare brown and green should be cut off or insulated.

It works! I can drive a Raspberry Pi from my laptop with just this one cable. Very handy. Just be careful to plug it in to the right place on your Raspberry Pi’s GPIO connector, right in the corner. Any other location will apply 5 volts to a pin which isn’t expecting it, and could damage your Pi.

There are a couple of finishing touches, however. I like to be allowed the responsibility of logging in as root, which Raspbian normally has disabled. It may not be good for schoolchildren to be able to do this, but for embedded developers fiddling with kernel drivers, it’s a great time-saver.

To enable root logins on the serial port, you’ll need to:

Enable the password on the root account:

sudo passwd root

Then enter your desired root password twice.

Enable root login on the serial console:

echo ttyAMA0 >> /etc/securetty

That’s it. You’re all set.

Dangerous Counterfeit Mains Cable

Leave a reply

The other morning I went to plug in a piece of equipment on my work bench. It needed a standard IEC-type power cable. My workshop, like many others, has a box in the corner containing an assortment of such power cables. I can’t remember where most of them came from, and I just grabbed the first one.

It seemed rather short, only about one metre long. That didn’t matter for this job. But I noticed that the insulation was damaged near the IEC connector. Oh dear. That makes the cable unsafe to use, so I set about destroying it before throwing the parts away. My usual technique for that is to put one foot on the plug and pull hard, tearing the cable out and rendering the whole thing unusable scrap. But I got a surprise: the cable more or less came apart in my hands!

I examined it more closely and found the oddest colour code I’ve ever seen:

Where on earth is the mains wiring colour code blue, black and black with a turquoise stripe? Not anywhere in Europe, that’s for sure. I looked further, taking the fuse out of the plug. Sharp-eyed readers will already have noted that the fuse is rated at 3A but coloured brown. That’s an oxymoron: under the British Standard BS1362, 3A fuses are red and 13A fuses are brown. So which was this one? It certainly doesn’t comply with the standard in spite of the ‘BS1362’ written on it.

Time to test the fuse. I hooked it up to my big power supply, and cranked up the current.

Yes, you read it right. This fuse labelled ‘3A’ carried 26.6A for long enough for me to pose it for a photo, pick up the camera and press the button. It blew a few seconds later. That’s the sort of behaviour I’d expect from a 13A fuse, not a 3A one. Oh dear.

I went back to the cable, and noticed that I could easily pull apart the insulation – both the thick outer and the inner cores – with my bare hands. No tools required, not even fingernails. That’s unbelievably dangerous. Once I’d peeled some insulation off, there was hardly any copper inside the wires:

My finger-in-the-air estimate of the safe current carrying capacity of this wire would be less than 1A.

What a cable. The connectors on both ends (which I forgot to take a photo of) were covered with various approval logos. I can’t believe this thing met any safety standards. The wire itself was so weak that it could be peeled back to bare copper with just my fingers. The plug fuse was mislabelled and far too large for the rating of the cable. The cable was so thin it wouldn’t handle the load that an IEC connector is designed for without dangerously overheating. If a fault had developed in the appliance plugged in with this cable, it’s likely that the cable would simply have caught fire before the fuse blew.

I believe that this cable was supplied with a Chinese USB hard drive enclosure I bought a few weeks ago, but I can’t prove it. If you buy cheap electrical goods, check the mains cable carefully. I don’t know whether to call this one fake, counterfeit or just bad, but it was certainly a death trap.

Bubble Development Board Ethernet and SD working

Leave a reply

I’ve got a couple more features of the Bubble development board working. The Micro SD card needed pullup resistors from its data and command/data lines, then it Just Worked though the card detect function doesn’t do anything yet. While modifying the VHDL to get Ethernet working (see below) I noticed a message that sd_card_detect has been optimised out of the design because it’s not connected to anything. That would explain it. I’ll look at it in a while. I’m not even sure whether the kernel driver supports a card detect line.

Most excitingly, Ethernet works now. I’ve connected its interrupt output to a register in the CPLD and modified the platform code in the kernel to point it at the relevant interrupt, and it works! It gets an address by DHCP and I’ve successfully copied files to and from it by scp. It seems a bit slow, topping out at about 3.5Mbit/s, but the Samosa bus timing is pretty relaxed and could probably be speeded up significantly. I saw one transmit timeout message, too, so maybe something isn’t quite right yet. Oh, and the MDI/MDI-X negotiation still seems a bit unhappy so the link doesn’t come up every time.

I’d also like to wire the ‘link’ output of the W5100 to a GPIO so that the driver can see it and do sensible things when the cable gets plugged in and unplugged.

Super Breakout to JAMMA Part 2: Colour

Leave a reply

The original version of this blog entry was published on the wrong date. You can find the correct page here.

Raspberry Pi Power Architecture

2 Replies

Embarking on some work with the Raspberry Pi recently, I wanted to know what its power architecture looked like. The schematic diagrams are freely available but a quick web search didn’t reveal any higher-level design documents like this, so I drew my own and here it is.

I offer no guarantees of accuracy. Don’t blame me if you use this documentation and destroy your Raspberry Pi or anything else. This is not an official document. I hope it’s useful to someone.

The original version of this that I posted in April 2013 had a mistake in it, which Kai kindly pointed out. The version below has been corrected.

There’s a nice shiny pdf of it here: Raspberry Pi Power Architecture

Bubble Development Board – progress

Leave a reply

Having now had the Bubble Development Boards for a few days, I’ve tested a few more features.

Both JTAG sockets (Xilinx 14-pin and ARM 20-pin) work with their respective dongles.

The Ethernet adapter, a Wiznet W5100, is showing signs of life. If I plug an Ethernet cable into it, the ‘link’, ‘full duplex’ and speed indicator LEDs come on. Frequently the ‘link’ LED blinks continuously along with the Rx LED. I don’t know why, though searching on the web indicates that the W5100 can be fussy about the choice of transformer it’s used with, and sometimes about what kind of hub it’s plugged into – apparenly the automatic MDI/MDI-X negotiation can get confused. The tests were done with a TP-Link TL-SF1005D switch and I haven’t tried any other. Sometimes, though, the link will settle down to a steady state, then I see the Tx and Rx LEDs doing sensible things.

The W5100 chip is wired to the Samosa bus with very simple address decoding so that it should appear every 4 bytes across the whole 256-byte Samosa address range. Manually poking and peeking its registers from the Bubble board’s boot loader gave sensible results, and I even managed to get it to try and send a packet, the Tx LED blinking reassuringly.

Recent Linux kernels have a driver for the W5100. I tried kernel version 3.7.1 which has already been patched for the Bubble board. The existing drivers expect the chip to be I/O or memory mapped, which is not the case on this board because it’s on the Samosa bus. The Samosa bus is accessed using its own function calls inside the kernel. I patched the driver, and had to undo one or two assumptions made in the code about memory access, and the results are promising: the chip is found correctly, interface eth0 appears, and it even sends packets from the DHCP client attempting to get itself an address. However, the first attempt to send a packet results in an error:

NETDEV WATCHDOG: eth0 (w5100): transmit queue 0 timed out

and a stack trace, though the kernel carries on running. It seems that the Ethernet chip’s interrupts are not making it into the kernel. This turns out to be due to the offending interrupt line not being connected to anything in the Bubble board’s CPLD, so I’ll have to fix that next. That needs the Xilinx programming dongle which I haven’t got with me at the moment.

Bubble Development Board – first prototypes received

1 Reply

A couple of days ago I received the first examples of the Bubble Development Board and started testing them.

Much to my joy, the board fits neatly into a low-cost plastic case from Farnell, part number 1526699. With front and rear panels suitably cut out, it should be well protected and easy to connect things to.

But does it work? Well, yes, largely. Here are the results so far.

Power: the LEDs (green for +5V input, orange for VDD_IO from the Bubble) come on and the Bubble board starts up reliably.
Reset button: does what it says on the tin.
Serial port: console works.
USB host: tested to work with a memory stick and a USB-to-Ethernet adapter.
USB slave: working. USB networking connection successfully established to a desktop PC as documented at http://www.balloonboard.org/balloonwiki/USBNetworking.
Audio: output works, straight into a pair of headphones, and quality seems good with no unpleasant background noises. Haven’t tried input yet.
HDMI: the Bubble board I was using was set up to drive an LCD panel, but by installing fbset and fiddling around with the settings (making them roughly 800×600, 60Hz) I managed to get a display on a monitor connected to the HDMI port. However, the image tends to disappear every few seconds and then come back again with some flickering, so something’s not quite right. I tried another monitor via an HDMI-DVI cable with the same result.
Micro SD socket: not working yet. The kernel reports an error during boot and /dev/mmc* devices don’t appear. I’ve noticed that other implementations of the SD card socket from Bubble have pullup resistors on all the data and clock lines which I neglected to put on this board. This might be an easy fix because the wiring looks right.
JTAG, Samosa, Raspberry Pi header, Ethernet: not tested yet.

Here’s another picture with the Bubble board turned over so you can see what’s on it.

HP 16534A triggering problems

30 Replies

One of my HP 16500B logic analysis systems has a 16534A digital oscilloscope module installed. The module has a great specification: two channels, 2Gsamples/sec, 500MHz analogue bandwidth, and 32k record length. I would find it a really useful debugging tool, if it worked properly. Sadly it doesn’t.

Though it displays a trace successfully, and the controls work, it won’t trigger. The only way I get a trace is by auto-trigger. In this case the trace isn’t synchronised, so it’s impossible to catch a particular event at a particular time. Here it is displaying a square wave (well, it’s nearly square – I hadn’t adjusted the probe compensation so it’s a bit curvy on the top and bottom). Adjusting the trigger level just doesn’t make any difference.

The service manual for the 16534A isn’t very helpful. It describes roughly what the self-tests do, and how to run the self-calibration procedure, but has no detailed circuit information. The self-test reports a ‘D/A’ failure:

and the self-calibration procedure fails on the Trigger and Hysteresis sections:

The service guide describes the D/A test like this:

Test DAC This test verifies the correct operation of the D/A convertor on the board.
Both the offset and trigger level D/A convertors for each channel are set to a reference
level and then changed. The logic trigger IC is programmed to detect the changes. The
detection of a correct trigger indicates that the D/A convertor is operating normally.

It seems clear that the offset D/A converter is working, since the offset control works and moves the trace up and down as it should. However, the trigger level control doesn’t seem to be doing what it should. I had a look at the board, looking for components likely to be the DAC or trigger IC. Unfortunately, the semiconductors on there seem to be mostly either standard ECL logic, trivial things like op-amps, or magic custom HP chips with dozens of pins. One exception was this:

It’s an AD96687 from Analog Devices, which is a dual high-speed comparator with ECL outputs. If I was designing a high-speed trigger circuit using 1994-vintage components, I might use a device like this. I’ve had a look at all its pins with the power switched on and a signal applied and tests running, and none of them seem to change at all. One noninverting input is stuck at +5V, and the other inputs are near ground. One set of outputs isn’t even showing valid ECL logic levels, but it may be unused and thus have no load resistors on it.

Maybe it’s a red herring and nothing to do with the triggering at all, but I’m suspicious that I never see anything change. Without more circuit information, it’s hard to get much further, sadly.

How to Get a Real Serial Port – PCI Express under Linux

2 Replies

I do a lot of hardware and software development on things with embedded processors, ranging from little 8-bit Atmel chips to big 32-bit ARM-based things like the Balloon Board. Often the systems they’re built in to don’t have much of a display or keyboard, so getting information in and out of them for testing and debugging purposes is tricky. One thing that really helps is a good old-fashioned serial port. Pretty much every embedded processor has some kind of serial port on it, and they’re generally very easy to use from software so can be got working very early in the development process.

In order to make use of a serial port, you need another one to connect it to. This used to be easy: they used to be ubiquitous on desktop and laptop PCs. However, in the last 10 years they’ve gradually died out and been replaced by USB to serial adapters. Though such adapters are cheap and readily available, I’ve had loads of problems with them. Since they’re easily detached, they often seem to go missing, or get left in toolboxes and attached to projects. Some of the ones I’ve used also sometimes seem to get themselves in a mess and start turning my data into junk until they’re unplugged and reinserted. This is not helpful.

It can also be hard to predict how the serial port will be identified when it’s plugged in: under Windows, it gets a COM port number, but which number it gets depends on how many other such devices have ever been plugged into that machine and even into which USB socket, so setting debugging software up to find the one you want is impossible. Under Linux the same problem exists but with an extra feature: if you have a terminal program watching a serial port, then accidentally unplug it and plug it back in again, the program carries on as if nothing has happened but you don’t see any output . That’s because the operating system thinks that the old port is still in use even though it’s not there any more, and allocates a new, available number when it’s plugged back in, so /dev/ttyUSB0 magically becomes /dev/ttyUSB1. Even restarting your terminal program doesn’t work, because it’s still going to look at the old number. You can reconfigure the terminal program to look at the new one, but then you’ll find that if you shut everything down and restart it, the USB serial port will have moved back to /dev/ttyUSB0. The only way out is to stop the program, unplug the adapter again, plug it back in and restart the program. This is a serious pain.

I recently had the chance to do something about this problem in my own workshop. I was configuring a new Linux PC for the workbench, and discovered, to my great joy, a little-documented feature on the shiny new Gigabyte GA-Z77N-WIFI motherboard: a serial port! Tucked away on a little white connector, there it was, forgotten and unloved. All it needed was a cable to bring it to the outside world, and it worked. It turns up as COM1 under Windows and /dev/ttyS0 under Linux, and it’s always there, can’t be unplugged, and never changes its number. Wonderful.

If one serial port is good, more must be better. The motherboard has a PCI Express slot on it, intended for a turbo-nutter graphics card which this machine didn’t need. I found a PCI Express serial port card, similar to the PEX4S553 from Startech.com which looked like it would do the trick. Actually I had it lying around because I’d fitted it to a Mac Pro a couple of years ago, but it never worked properly in the Mac.

I put it in the machine and switched on. Would it work? Typing lspci revealed that it was there, and was working, so were the ports usable?

ls /dev/ttyS*
ttyS0    ttyS1    ttyS2    ttyS3

Not bad, but why only four? There’s the one on the motherboard, plus four on the card, so that should be five, right? Well, to cut a long story short, after a bit of web research, I found that the standard serial port driver in the Linux kernel only looks for four serial ports as standard, but responds to a kernel command line parameter to make it look for more (or indeed less). Experimentally rebooting and manually editing the kernel command line in grub to add

8250.nr_uarts=5

to the end of it worked! I had all five ports, and they all did what they should. To make the change permanent, I edited /etc/default/grub to add 8250.nr_uarts=5 to the end of the GRUB_CMDLINE_LINUX_DEFAULT parameter, and ran update-grub. Now all five ports turn up every time I switch the machine on, and I’m a happy developer. By the way, I’m running Debian Linux 6.0 (squeezy) with kernel version 3.2.something from backports, but the kernel version won’t make any difference – this stuff is all ancient history.

It remained only to tidy up the wiring. The ports on the Startech card appear on 10-pin headers. The wiring on these is simple: pin 1 on the header goes to pin 1 on the 9-pin D connector, pin 2 to pin 2, and so on. Pin 10 isn’t used. However, the way the pins are numbered differs between the headers and the D connectors: the headers are numbered on alternate sides, like a street, so one side is 1/3/5/7/9 and the other is 2/4/6/8/10. The D connectors are numbered 1-5 on the top row and 6-9 on the bottom row.

I had a load of serial port breakout cables in the bottom of my PC parts box, left over from the early 90s. I found that many of them were wired straight-through, like this:

which is wrong for the Startech card. I had to rewire them to look like this:
:

according to the correct pin numbering, and then they worked. The card fitted neatly in the back of the machine:

and, as a finishing touch, I did a ‘case mod’ to mount two of the serial ports on the unused 3.5″ floppy drive blanking plate:

Notice how they’re labelled, so I always know which is which! It’s a very practical arrangement for the workbench, having reliable serial ports always at hand. The other two are round the back, and will probably be used less frequently.

Motorboating in Space

Leave a reply

Or, how to stop Zaxxon going thump-thump-thump.

‘Motorboating’ has been a problem in electronics almost as long as electronics has existed. It gets its name from a characteristic thumping or buzzing noise, reminiscent of a motor boat’s engine. It’s a problem which usually occurs in audio amplifiers, and it happens either because of a design error or faulty components. Sometimes a change in an amplifier’s operating environment, such as a radio battery running down, can cause it. It’s loud, annoying, and can even damage speakers,

The reason for the noise is feedback. If an amplifier drives a signal into a loudspeaker, the power for that signal has to come from its power supply. Its power supply, especially if it’s a run-down radio battery, isn’t perfect. Drawing power from it makes its output drop in voltage for a moment. Unfortunately, electronic circuits aren’t perfect either. Their behaviour is strongly affected by their power supply. Connect such a circuit to such a power supply and amplifier, and you have a vicious circle: circuit sends a signal to amplifier, amplifier sends it to speaker and draws more power, power supply affects circuit, which makes another signal which gets sent to amplifier, and so on. It’s called feedback because the output signal feeds back into the input, via an unorthodox route. The circle of feedback can lead to the regular buzzing noise – the motorboating.

Recently I have restored a Zaxxon arcade game circuit board, which dates from 1982 (actually, it’s a bootleg, but the circuit is largely the same). I got it working well, but with one big problem: the sound was accompanied by a constant thumping noise which wasn’t supposed to be there. Here’s a short movie of how it sounded. It’s especially noticeable at the start and end of the clip.

Fans of the game will know that Zaxxon has very distinctive sound. Many video games at the time used digital techniques, often using standard chips, to generate their sound, which gives them a characteristic bleepy quality. Zaxxon is different. It uses what amounts to an analogue synthesizer: a magnificent assembly of timers, oscillators, amplifiers and filters. It has a lot in common with the kind of instruments used in pop music at the time. It makes a glorious, raucous noise.

But this kind of analogue circuitry has a problem, especially when it’s cheaply built using early 1980s technology: it’s very sensitive to its power supply. Any variation in the power supply basically gets straight to the synthesizer’s output. What’s more, Zaxxon’s loudspeaker amplifier runs from the same power supply as the synthesizer. This lot is a recipe for motorboating, and that’s exactly what happened to my game.

Of course, we have to assume that it all worked properly when it came out of the factory, but then it would have been running from an official Zaxxon power supply. The one I use in my arcade game test rig may not be as good as the original one, but it’s good enough for most things, and I wasn’t going to change it just to fix this problem. So I had to come up with a modification to keep apart the amplifier power and the synthesizer power.

The traditional cheap and cheerful way of keeping power supplies apart, known as decoupling them, is simply to put a resistor and capacitor between them, like this:

This decoupling means that variations in one power supply have a smaller effect on the other. It works well, and has been used in millions of electronic devices from the earliest days of radio. However, a certain amount of power is always lost in the resistor. Many circuits don’t mind this, or can be designed to handle it. I tried this approach with Zaxxon,and it turned out that the sound synthesizer doesn’t cope well with a reduced supply voltage. Many of the effects, especially explosions, became disappointingly quiet. I had to find another way.

Arcade games typically use two power supplies: 5 volts for their digital circuits, and 12 volts for the sound amplifier. This gave me an idea: how about using the 5 volt supply to run the audio synthesizer, keeping it neatly separate from the amplifier? Clearly the synthesizer wouldn’t just work from 5 volts: I’d already had trouble with it running from about 10 volts in the decoupling experiment. However, there was a solution. It would be possible to boost the 5 volt power supply up to 12 volts using, aptly, a boost converter. Boost converter modules are cheap and readily available thanks to low-cost far eastern manufacturing. The one I chose had a conveniently adjustable output voltage. It didn’t take long to wire it up. I’d already separated the amplifier supply from the synthesizer, and so I just had to take a wire from the existing 5 volt supply to the sound board, check my work and switch on.

It worked! The sound was now perfect, with no strange thumping effects, and everything seemed to be at the right volume. It remained only to make the modification more solid, and there was even a handy spare hole to mount the boost converter in. Job done!