Category Archives: Projects

Sony WM-D6C Walkman Pro DC-DC converter repair

This story starts with the long drive from Cambridge, UK to Warsaw, Poland. I like to be able to listen to music to while away the hours in the car, and I decided to use cassettes. Why? Our car radio is faulty, so much of the time there’s hardly anything to listen to. It has a CD player, but almost all of my CDs are stored away, having long since been converted to MP3s. There’s a handy AUX IN jack, so I can plug in my smartphone. But there’s simply no way to operate a smartphone without looking at it, and I’m not taking my eyes off the road at Autobahn speed.

My solution? Cassettes! I’ve got lots of them, generally high quality recordings, which I’ve never digitised, so they’re not stored away. They’re easy to operate with one hand without looking at them, too. But the car has no cassette player. Sorry, had no cassette player. A little judicious eBay shopping got me a Sony WM-D6C Walkman Professional in immaculate condition for a somewhat lower-than-average price because it didn’t work.

IMG_20190101_132309

The WM-D6C is widely acknowledged to be one of the finest portable cassette machines ever made. It’s pocket-sized, if you have large pockets, and has sound quality and features that rival full-sized hi-fi cassette decks. It can also record, which is extremely unusual for a Walkman-format machine.

This particular example is a very late one. It doesn’t have the posh amorphous head of the original models, but the electronics are mostly easy-to-access surface-mount components rather than the gruesome bird’s nest of wire-ended parts that the early models had. I remember servicing an early one for a student radio station and it wasn’t a lot of fun. I think this one must have expired quite early in its life and been left on a shelf, because there’s no perceptible head wear and the casing is unmarked.

Putting batteries in and pressing play resulted in the ‘BATT’ LED coming on but absolutely nothing else. No clicks in the headphones, no motor whirring, nothing. Fortunately the service manual is readily available on line. ‘Supplement 4’, dated 2001, accurately describes my example.

Browsing the circuit diagram revealed one of the secrets of the WM-D6C’s excellent performance. Most Walkman-type cassette machines used a pair of ‘AA’ cells, so all the electronics had to run from just 3 volts. That’s common enough in 2018, but back in the day it was a real challenge, so the capabilities of the motor and electronics were compromised. The WM-D6C not only runs from four ‘AA’ cells, for a 6 volt supply, but does even better. Almost the first thing it does is step up that supply to about 11 volts. That rail then runs nearly everything, including the motor and audio circuits. A nice generous supply voltage is a good start for getting top performance, especially with 1980s-era technology.

A quick prod with the multimeter revealed the problem. This boosted supply was entirely absent. Seeing as how it powers most of the machine, that would explain the lack of results. The supply rail comes from a much-feared component, the DC-DC converter (CP304). Inscrutable in its little screening can, labelled ‘SONY’ on the right hand side of the picture of the Walkman’s entrails below, it’s often considered unrepairable.

IMG_20181002_151808

The service manual includes a somewhat misleading diagram of its innards. I think the diagram is actually back-to-front, showing the output and input swapped, because that’s the only way it makes sense. The NPN transistor makes a boost converter in a variation on the classic ‘joule thief‘ circuit, and the PNP one with works with the zener diode to regulate the output by depriving the switching transistor of bias if the output voltage rises too high.

WM-D6C DC-DC converter

The converter wasn’t too hard to remove and dismantle, given reasonable desoldering tools and a powerful iron to unsolder the can. Here’s what’s inside. There are components on both sides of the board, and a certain amount of grey silicone which is easy enough to peel off. Back in the 1980s this would have seemed intimidating in its compactness, but it’s easy to work on given modern tools.

Finding the fault was a case of looking for the ‘usual suspects’: there were two tantalum bead capacitors sitting there looking guilty. The one on the input was short-circuit, which had killed off the 22uH inductor connected to pin 3, the large green component on the right.

I replaced the faulty components, using a higher-voltage-rated tantalum and a ceramic chip in parallel to replace the capacitor, and a surface-mount inductor with bits of wire soldered on to it. The values aren’t very critical and I just used what happened to be lying around. A quick test, giving it 6V from a bench power supply, revealed a healthy 11V or so at the output.

After reinstalling the converter and reassembling the machine (watch out for the little ‘speed tune on/off’ knob at the back) it worked! It shows signs of having had attention from the phantom twiddler. The head azimuth adjustment screw was tightened up, but good quality sound returned when it was properly adjusted. The peak level meter seems rather unenthusiastic so may need adjustment, and I haven’t checked the recording bias yet. There’s also a forest of little surface-mount electrolytics waiting to dribble corrosive ooze all over the PCB, but that’s a job for the long winter evenings. For now, it’s working. Being able to play cassettes has turned out to be unexpectedly useful. We rediscovered a tape of nursery rhymes from Domowe przedszkole, a classic Polish children’s TV programme, which granted us peace on a long trip recently!

Quick-and-dirty partition resize with Acronis True Image

Leave a reply

A little embedded Linux magic comes in unexpectedly handy. Years ago, I started using Acronis True Image to back up my office PC. Other backup packages are available, as they say, but it’s worked well enough for me. This week I had reason to use it in earnest.

img_20180619_112420

The PC is set up with two main partitions on the disk. There’s one for the operating system (Windows 10) and applications, and another with data on it, analogous to the /home partition on a Linux system. Inevitably, it turned out that the boundary between these partitions was in the wrong place. The operating system partition was full, and things were starting to fail. Time to make sure the backup is up-to-date and then to restore to differently-sized partitions.

The operation fell at the first hurdle. Acronis True Image will create a ‘recovery’ USB stick from which the PC boots. This contains a small Linux distribution (Acronis Linux) and a GUI for managing the recovery operation. My backups are on a network drive, which happens to be an Apple Time Capsule. Would the Acronis recovery system connect to the Time Capsule? Would it ever. I couldn’t even persuade it to ask for the username and password, though it could see the Time Capsule on the network.

In Acronis Linux, pressing ctrl-alt-F2 in time-honoured fashion brings up a command line. Yay! Power! A bit of digging reveals a command called asamba which can connect to SMB shares. Using that, I could connect to the Time Capsule absolutely fine and mount it to the local filesystem. So why couldn’t the GUI do it? Annoying.

My next trick was to copy the backup from the Time Capsule to a USB hard drive using another Linux PC. It took a while for the several hundred gigabytes, but it got there. Acronis recovery will read USB drives, so the next step should be easy, right? No. My USB drive happened to be formatted ext4. Though Acronis Linux is perfectly capable of mounting ext4 filesystems, the recovery GUI only acknowledges the presence of FAT and NTFS discs. Aargh!

The solution was to mount the USB drive on my Linux PC, then share it using Samba. Acronis recovery found and let me log on to the Samba share, and could thus see the drive and backups.

Changing the partition sizes was the next problem. The GUI only allows you to shrink partitions or to grow them in to free space. My disk didn’t have any free space. It was all partitioned and in use. I thought that shrinking the data partition would create free space that the operating system partition could grow in to, but I was caught out by the presence of a 500MB ‘recovery’ partition which Windows had sneaked in between the two. I don’t know what it’s for but I didn’t feel like taking the risk of destroying it. There are no tools in the Acronis GUI for deleting partitions and starting again, so I was stuck.

img_20180619_113338

Command line to the rescue! Ctrl-alt-F2 again, and there’s a perfectly good copy of fdisk available. It was a moment’s work to delete the existing recovery and data partitions, then ctrl-alt-F1 to the GUI. Restart the restore process and there’s free space available for the operating system partition to grow in to, and plenty of room to create new recovery and data partitions.

img_20180619_112939

The restore took a few hours, as expected, but was successful. The only wrinkle was that Acronis recovery had marked the recovery partition as active rather than the boot partition, so the PC complained that there was no operating system. Another trip in to fdisk to mark the boot partition active sorted that out, and now I’m typing this very text on the PC restored to working order.

Footnote: there is another Acronis restore tool intended for restoring backups to dissimilar hardware. This may have handled the partition resizing more elegantly, but I didn’t try it.

Good accuracy from a low cost Real Time Clock

1 Reply

One product I work on has a built-in data logger. This helps us a lot if a problem occurs: we can see the history of any faults. Every log entry is time stamped, which is important. We need to know when it’s been used and how often. However, good timekeeping is a challenge. The product has no Internet connection, it gets stored and moved around a lot, and it’s nobody’s job to check or adjust its clock, so there’s a real problem with clock accuracy.

The real time clock is based on the Microchip MCP7940N chip. The chip uses a standard 32.768kHz crystal for its timekeeping. These crystals are fickle beasts, partly because of the very low-power oscillator in the chip. The oscillator frequency, which is critical for accurate timekeeping, is very dependent on the load capacitance, which itself can vary with different builds of the PCB. The heat of soldering during manufacture also affects the crystal. I’ve seen plenty which have failed altogether, and others whose frequency has shifted significantly. Note the soldering on the crystal’s load capacitors C9 and C10 in the photo below, part of an attempt to find the optimum load capacitance on a prototype board.

All of these issues mean that just assembling the PCB and hoping for the best doesn’t work well. The frequency of an apparently working crystal can be anything up to 100ppm (parts per million) wrong. That doesn’t sound like much, but it works out to nearly an hour’s error per year, which is pretty bad.

Fortunately the MCP7940N has a neat feature which helps a lot. One of its registers, called CAL, holds a value which speeds up or slows down the clock by a small amount, like the regulator on a mechanical clock. But how do we know what the error is, and whether it’s been successfully corrected?

The MCP7940N also has a pin which can output a 1Hz square wave derived from the oscillator. With a sufficiently accurate timer, it’s possible to measure the error in the crystal’s frequency this way.

Checking the correction is more difficult. Because the chip only works on whole oscillator clock cycles, it does the adjustment to the clock’s speed by adding or removing a few clock cycles each minute. It’s therefore necessary to measure the period of exactly 60 of the chip’s seconds to find out how long its minute is, and therefore how accurate the whole clock is.

Getting a sufficiently accurate timer is the first problem. My aim was to get the MCP7940N to be accurate to within 1ppm, or about 30 seconds per year. A useful rule of thumb in metrology is that the measuring instrument needs to be ten times more precise that the quantity being measured, so we need a timer accurate to 0.1ppm, or one part in ten million. To the rescue comes my trusty Hewlett Packard 5335A universal counter. It’s an oldie but a goodie. Mine is fitted with the optional oven-controlled crystal oscillator, an HP 10544A. I checked it and set it up against a Rubidium frequency standard about 8 years ago and it hasn’t been touched since. I checked it this month against the same frequency standard, and it still agrees to within 0.1ppm. Not bad, and certainly good enough for this job.

Measuring the initial clock error is easy enough: connect the counter to the MCP7940N’s 1Hz output and look at the error. The 5335A counter has handy built-in maths functions to make this easier, so it will directly display the difference between its idea of a second and the chip’s attempt.

To measure the corrected clock output over a minute needs a bit more trickery. The 5335A counter has an external ‘arm’ input, and can average a period reading over the length of the ‘arm’ signal. All that’s needed is to arm the counter for 60 seconds and the counter will do the rest. I couldn’t find a way to make the counter do this for itself, so I cheated and used a spare Arduino mini that happened to be lying around. All it had to do was wait for a clock pulse on a GPIO pin, take another GPIO pin high to arm the counter, count 60 clock pulses, then take the arm signal low. Simple.

The test setup looked like this. The scope is there for ease of probing (note the cable from its ‘sig out’ connector to the counter) and it also includes a Tektronix 7D15 timer/counter module connected to the chip’s output. The 7D15 is a lot less accurate (about 1ppm) than the 5335A but it’s good enough to give an idea of what correction is required. The Arduino mini is just about visible at the bottom of the photo.

Here’s a closeup of the scope screen, showing the measured period of the clock’s 1Hz output, 999.9818ms. That’s just over 18ppm too fast.

This the setup screen of the product, showing the 18ppm correction applied to the MCP7940N’s CAL register.

Finally the error in the measured minute, calculated by the 5335A counter gated by the Arduino.

It’s showing that the corrected minute is 301.3 parts per billion, so 0.3ppm, too fast. That’s as good as it’s going to get – about 10 seconds per year. With the clock set up using this process, it has a fighting chance of staying accurate in the real world.

The Euroquadruped, or the solution to wall wart Tetris

Leave a reply

Having relocated from the UK to Poland, the change in mains plugs has never quite been resolved. All the equipment that came from the UK has 13A plugs on it, and all the local sockets are the CEE 7/5 type. Then there are locally-acquired bits and pieces which generally have two-pin Europlugs. No matter how many adapter cables and extension leads I make, or change the plug or socket on, there’s always something that doesn’t fit, or won’t reach the nearest compatible socket.

Of particular annoyance are various chargers and wall warts. They’re all bigger than a standard Europlug, and there’s no standard for which way the ‘lump’ of the charger will be attached, so connecting several of them in to a multi-socket extension lead doesn’t work well. Often one charger will obscure one or more sockets in such a way that all the things you need just won’t fit, or the whole assembly becomes so big and unwieldy that things start falling out under their own weight.

It is therefore with some relief that I announce the debut of the Euroquadraped: one 13A plug with short cables to four Europlug sockets. It reminded me of an octopus but only has four ‘legs’, hence the name.

Getting all four cables in to the 13A plug was a bit fiddly, but choosing a roomy plug helped. The little Europlug sockets are neat. I’ve only seen them here in Poland. The finger ring to discourage pulling on the cable is a nice touch, and doubles as a cord grip internally. They even (finally) have safety shutters on the socket holes, roughly 60 years after shutters became standard on the British 13A socket…

The great advantage of this thing is that each socket is independent of the others and can find its own equilibrium with whatever electrical carbuncle is plugged in to it.

It’s trivially simple, but it’s going to save a lot of frustration in the workshop.

Garage door opener life extension

Leave a reply

This little thing is really annoying. It’s the remote control for our electric garage door, and I use it several times a day to get my bike in and out. Luxury, pure luxury. Or it would be, if it worked properly. The trouble is that about half the time after pressing the button, it locks up, stuck either on, with its little red LED lit, or off, so it won’t open or close the door, and drains the battery. The only way to fix it is to pull it apart, take out the battery, and put it back in without losing any of the bits of plastic. You can imagine how much fun that is with gloves on, in the rain, when you’re in a hurry. Yeah, yeah, first world problems, I know. But there doesn’t seem to be any way of opening our garage door manually, which is a nuisance.

Inside is a little PCB containing a PIC12F635 microcontroller and a simple 433MHz transmitter circuit using a couple of transistors and a resonator. I did all the obvious things: replace the battery, clean the board with solvent, all of that. Nothing helped. It seems there’s a bug in the PIC’s software which makes it prone to locking up. The switch under the button is rather worn and thus suffers from contact bounce, and I think that’s what’s upsetting it.

I tried filtering the signal from the button to the PIC with an RC network. That didn’t help: the PIC didn’t even respond to the button any more. Presumably it needs a fairly quick risetime to trigger an interrupt, or something similar.

There is a second button which is less worn. It transmits a different code which doesn’t seem to do anything on our garage door, but it never crashes the PIC. I considered swapping the switches over, but they’re surface-mount and glued down, and the chances of removing both of them and successfully soldering them down again undamaged were slim.

I wondered about rewiring the PCB so that the input to the PIC is always active, and the button just switches the power to the PIC. A quick test by adding a blob of solder and removing and reconnecting the battery showed that wasn’t going to work: the PIC just didn’t transmit. It needed to have the power applied and then have the button activated.

There was another issue to address. The button, when it worked, was prone to getting pressed by accident as the bunch of keys rattled around in my pocket. That led to the garage door opening itself at odd times, which wasn’t great for the security of our bikes. Somehow modifying it to be less prone to accidental operation would be nice.

Design changes were called for. Since the second button is redundant, I decided to convert it in to a power switch, so it has to be held down while the real button is pressed, and releasing it will guarantee that the power is cut from the PIC so it can’t remain locked up. I cut the power track to the PIC and took advantage of the PCB layout to add a P-channel MOSFET in series with it, then cut the track from the second button to the PIC’s input and wired it to the MOSFET’s gate. The buttons both have one terminal to battery negative. A pullup resistor between gate and source completes the circuit.

Here’s the modified board. You can see the remnants of some of my previous repair attempts, and the extra MOSFET and pullup resistor at top right. Now, to open or shut the door, I have to hold down the button on the right and press the left button, rather like using a shift key on a keyboard.

It seems to work reliably now, so leaving the house and returning are considerably quicker and less stressful.

Incidentally, I did the repairs and modifications in the office, which is several miles away from the offending garage door. To check that the remote was actually transmitting properly, I used my Tektronix 7912AD programmable digitizer with 7A29 vertical plugin. Originally intended for high-speed laser and nuclear physics research, it’s kind of overkill for testing a garage door opener, but its 700MHz bandwidth is plenty fast enough to get a clear picture of the transmission using just a loop of wire connected to the input. Analogue technology at its very finest. Here’s its TV output connected to a little LCD monitor showing the 433MHz signal from the remote.

Cracking a password-protected PDF file

2 Replies

Suppose you asked an insurance company for a letter. The insurance company kindly sent it as a PDF attached to an email. Sensibly, they protected that PDF with a password which they told you over the phone. You wrote it in a notebook and then left the notebook at work over the weekend.

pdf-password

How could you read the letter in the password-protected file at home, then? Remembering that the password was definitely an English word, and all in lower case, a dictionary attack has got to be worth a try.

Linux provides some handy tools for this. There’s a list of English words in /usr/share/dict/words, and a suite of PDF tools which can attempt to open the file using a password, indicating success or failure. A few minutes with Python and:

#!/usr/bin/python
import os,sys

wf=open('/usr/share/dict/words','r')
while True:
  word = wf.readline().strip().lower()
  if word == '':
    print "No solution found"
    break
  print word
  cmdline = 'pdftotext -upw "'+word+'" '+sys.argv[1]
  result = os.system(cmdline)
  if result == 0:
    break

The same thing must be possible in a more hipsterly fashion using awk, but I couldn’t be bothered to figure out a sufficiently baroque command line.

By the way, the password was ‘orange’. Don’t tell anybody.

Systemd for Embedded Linux

2 Replies

Over the last few years, there has been a lot of controversy in the Linux world about systemd. As I understand it, systemd is intended to be a better-engineered, more powerful version of the motley collection of little programs and scripts which keeps the essential services on a Linux system running.

systemctl

The controversy arises because the original 1970s Unix way of doing things was to rely on a motley collection of little programs and scripts for everything, each of which was simple but well understood, and to knit them together to form a complete operating system. Systemd takes a different approach, using larger and more sophisticated components which are more dedicated to particular tasks, such as managing services or network connections. This is supposed to make it more efficient and easier to manage in the twenty-first century.

I’ve been doing some work recently on an embedded Linux system which runs on the latest version of Debian Linux, version 8 (‘Jessie’). Debian Jessie fully supports systemd to the extent that it seems to be the default way of doing things. I thought I’d experiment with it a bit.

When working on an embedded Linux system, I very frequently want to have a piece of my software run reliably at startup, get restarted if it fails, and be able to output logging information to an easily-managed place. In this case, my software provides a D-Bus interface to a piece of industrial electronics.

In the past I’ve relied on copying and pasting scripts from other pieces of software, and managing log files has always been a bit of a mess. It’s hard to do these things right, so re-inventing the wheel is too risky, which means that the best strategy is to copy somebody else’s scripts. I have never counted the hours of my time which have been wasted by dealing with awkward corner cases and peculiar bugs due to recycled scripts behaving in ways I hadn’t anticipated.

What does it look like with systemd? There are some helpful tutorials out there, including this one from Alexander Patrakov, so it didn’t take me too long to put together a service file which looks like this:

[Unit]
Description=My D-Bus Gateway

[Service]
Type=dbus
BusName=com.martin-jones.gateway
ExecStart=/usr/bin/my_dbus_gateway
Restart=always

[Install]
WantedBy=multi-user.target

I’ve changed the names to protect the innocent, but the contents of the file are pretty self-explanatory. The [Unit] section just includes a description which is readable to a human being. The [Service] section describes the service itself. In this case it’s of type dbus, which means that systemd will check that the service name (com.martin-jones.gateway in this case) gets correctly published on to D-Bus. The Restart=always setting means that my software gets restarted if it exits. The [Install] section just indicates that this service should run when the system comes up in multi-user mode (like the old runlevel 5).

Having created this file, I simply copied it into /etc/systemd/system/my_dbus_gateway.service and, lo and behold, my new service worked. It was immediately possible to manage the service using commands like

systemctl start my_dbus_gateway.service
systemctl stop my_dbus_gateway.service
systemctl status my_dbus_gateway.service

Great! That’s exactly what I wanted.

Now for logging. I’d heard that systemd would log the stdout and stderr outputs of services into its own journal, and forward that to syslog as required. It does, but there’s a subtlety. Output from stderr appears in /var/log/syslog immediately line-by-line, but output from stdout gets aggressively buffered. This means that it gives the appearance of not working at all unless you explicitly flush the stdout buffer in your code using something like

fflush(stdout)

That’s the only wrinkle I came across, though.

In summary, using systemd’s facilities has made my life as an embedded Linux developer much, much easier and hopefully more reliable. That’s a good thing. My top tips for getting your software working under systemd are these:

Create your .service file using the recipe above and the documentation
Don’t forget to flush stdout if you want to see it in syslog.

Lattice FPGA programming adapter from the junk box

Leave a reply

Working with Lattice FPGAs recently, I had a need to program one but couldn’t find my ‘proper’ (Chinese clone, bought from eBay) programming adapter. When I started the Diamond Programmer software, though, it claimed it could see a USB programming adapter. It turned out that I’d left an FTDI ‘FT2232H Mini Module‘ attached to the PC. I use the module for all sorts of little debugging exercises: most often as a dual serial port for serial port debugging, but it also works for programming Parallax Propeller microcontrollers.

As luck would have it, the Diamond software recognises the unadulterated FT2232H as a legitimate USB programmer, and pressing the ‘Detect Cable’ button finds it. Note that if you plug in a new USB device, the Diamond Programmer software needs restarting before it can see it.

The FT2232H has two ports, A and B, and these appear as ports FTUSB-0 and FTUSB-1 in the Diamond software. All that remained was to figure out the wiring. Fortunately, there are a lot of clues in the schematics of various Lattice evaluation boards, particularly the MachXO2 Pico Board and the iCE40 Ultra Breakout Board.

Here’s the wiring, both for SPI and JTAG, referred to the pins on the Mini Module. I chose to use port B since it was more convenient for my prototype board. Translating the wiring to port A is left as an exercise for the reader.

SPI    JTAG  FT2232H  Mini Module
SO     TDI   DBUS1    CN3-25
SI     TDO   DBUS2    CN3-24
SCK    TCK   DBUS0    CN3-26
SS_B   ISPEN DBUS4    CN3-21
CRESET TRST  DBUS7    CN3-18
GND    GND   GND      CN3-2,4

It works well, and does exactly what it should.

First steps with a Lattice iCE40 FPGA

14 Replies

I’ve just been doing some work with the iCE40 series of FPGAs from Lattice Semiconductor. They’re small FPGAs, with up to 7680 gates, and they’re very low-power, which is nice for mobile applications. From what I can gather, Lattice acquired the designs when they bought a company called SiliconBlue in 2011. I’ve been used to using the Lattice Diamond software with their other chips, but the iCE40 chips aren’t supported by Diamond. Instead, they get their own software called iCEcube2. It’s a bit of a pain to use and not very well documented. I’ve just been through the process of starting a project and getting a very basic design working, and I’m writing about it here in case someone else finds it useful.

The iCEcube2 software looks convincingly like an IDE, but it isn’t, really. It doesn’t even seem to have a way of creating new source code files, and the order in which some things have to be done is not at all obvious. I think iCEcube2 is really designed for taking existing designs and implementing them on the Lattice iCE40 chips. While the software is a complete dog’s breakfast, it does have the key advantage of being free. You do need to create a node-locked licence for it using their licencing page.

To start an empty project, double click Project -> New Project. Select the chip you’re going to use. This creates a folder with the title of the project, containing:

<project>_sbt.project
<project>_syn.prj
folder <project>_Implmnt, containing folder sbt, containing folders constraint, log and outputs. All are empty apart from iceCube0.log in log folder.

Now you can add your source files. If you click on ‘Synthesis Tool’, then an ‘Add Synthesis Files’ menu item appears, but clicking on this doesn’t do anything useful. You have to right-click on ‘Add Synthesis Files’ and select ‘Add Files…’ from the pop-up menu. Go figure. I used a very simple VHDL source file:

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;

ENTITY test IS
 PORT
 (
 d: in std_logic;
 q: out std_logic;
 qn: out std_logic
 );
END test;

ARCHITECTURE rtl OF test IS
BEGIN

 q <= d;
 qn <= not d;
 
END rtl;

At this point I’d expect to be able to allocate signal names (d, q and qn, in this case) to pins on the device package. But you can’t do that yet in the wonderful world of iCEcube2. All the buttons on the toolbar are greyed out. The way to proceed is to double click ‘Run Synplify Pro Synthesis’. Hopefully your code will compile without errors, and lots of files get created.

The project folder now contains:

stdout.log and stdout.log.bak
synlog.tcl
loads of stuff under <project>_Implmnt

Two new files appear in the project under ‘P&R Flow’: <project>.edf and <project>.scf.

Now double-click ‘Run P&R’. The design will get placed and routed, and a bitmap gets generated for programming the chip.

At this point the toolbar buttons for timing constraints, pin constraints, floor planner, package view, power estimator and timing analysis become active. Hurrah! Now you can change your pin constraints.

Click on ‘Pin Constraints Editor’, the fourth icon from the left. Put in the pin locations for the signals you want. Make sure you click the ‘locked’ checkboxes on the left hand side, otherwise the place and route process is likely to move them. Press ctrl-S to save. The constraints get saved in <project>_Implmnt\sbt\constraint\<top design file>_pcf_sbt.pcf. You will then get asked to add the file to the project. Say yes.

If you’re using source control, it’s a good idea to add this file to it. I’m not so sure about all the other junk that iCEcube generates.

Now double-click ‘Run P&R’ again and the new bitmap file will be generated, using your pin constraints.

Programming an actual chip (or at least its SPI Flash ROM) needs the Diamond Programming tool, which comes as part of the Lattice Diamond software and *not* as part of iCEcube2. That’s just another couple of gigabytes to download, and another licence (free) to acquire, so it’s a pain, but it does work.

Orange Internet and port forwarding, continued

2 Replies

A long time ago, I wrote an article about how I worked around the lack of NAT loopback support on the Orange LiveBox broadband router. At the time, it was a pain to get everything working right. Having just moved house, we made the sensible decision to stay with the same broadband provider, in order to avoid having to re-invent or at least re-configure all this stuff.

Well, it turned out not to be as easy as that. Nothing ever is, it seems. The new Orange broadband service comes with a ‘FunBox‘ instead of a ‘LiveBox’. Fun? Who said? Not in my experience. The web interface to the box looks comfortingly similar to the old LiveBox, so I thought it would work the same way. No chance.

What’s the problem I’m trying to solve here? Well, I have a little SheevaPlug which hosts some services I need to use from various locations when I’m working. Yes, I know I should put those services ‘in the cloud’, but that would involve both paying money and solving a whole load of other problems. For years and years, I’ve simply had a port forwarding rule set up on my home broadband router so that the SheevaPlug is accessible from the internet. A little touch of dynamic DNS courtesy of dyn.com and it’s all worked fine.

Fast forward to 2015. I tried to recreate the setup I’d always used, but with the FunBox (hah!). The old setup went like this:

the broadband router just does the usual NAT routing and behaves as a dumb wi-fi access point. It has a port forwarding rule set up to forward port 22 (ssh) to the SheevaPlug
the SheevaPlug hosts my ssh server, and provides the DHCP and DNS services to everything on the network, so I get proper local hostname lookups, easy-to-manage IP addresses, and can solve the NAT loopback problem.

That’s it. I tried to set up the FunBox the same way. What could possibly go wrong?

I boldly switched off the DHCP and DNS servers in the FunBox and switched over to using the ones on my SheevaPlug. Everything seemed to work fine, except…the TV. Yes, the TV decoder is connected to the FunBox via Ethernet, so the whole shebang comes down the wire. No aerial required. Trouble is, the FunBox seems to need to set up the TV decoder by DHCP otherwise it doesn’t know it’s there, so you get no telly. Oh well, I’ll use the DHCP server in the FunBox and put up with the inconvenience.

Even that doesn’t work out. In order to solve the NAT loopback problem, which the miserable FunBox suffers from just like the LiveBox, I need to run my local DNS server. Except that the brain-dead FunBox won’t let you change the DNS settings on its built-in DHCP server. How annoying is that?

OK, accept that NAT loopback will remain a problem. Maybe I’ll find another way round that. Now for the showstopper: the blessed FunBox refuses to forward port 22. It will forward every other port under the sun, but not 22. The web configuration interface just won’t accept the setting: it ignores it. Doesn’t even give an error message. You’re just not having it. Oh well, maybe I have to expose my ssh server on a different port and put up with changing all the gazillion clients which know about it. Except I’ve still got the loopback problem. This is getting unpleasant.

Before tearing out what little remained of my hair by this point, I slept on the problem and had a brainwave. The FunBox supports a ‘DMZ’ feature, in which it’ll forward all incoming internet traffic to a particular IP address on the LAN. I tried it, experimentally sending all internet traffic to the poor, naked SheevaPlug, and it worked! At last, sweet relief: something which does what it says on the tin.

Clearly exposing the server in all its complacent insecurity to the internet isn’t a good idea. I needed to put a firewall in the way. A rummage in the cupboard produced a spare Raspberry Pi and a USB to Ethernet adapter. I programmed OpenWRT on to an SD card and booted up. It turned out to be easier to configure it through the command line than with the web interface, LuCI, which isn’t exactly finished yet. Some fiddling later and I’d managed to disable its DHCP and DNS features and enable incoming connections only on port 22.

Adding the firewall had another bonus: it meant I could re-enable my DNS and DHCP servers and let them look after the LAN without the wretched FunBox knowing anything about it. It just has to live a simple life, looking after the telly and the firewall. I disabled its built-in Wi-fi access point and added an ageing Linksys WAP54G running DD-WRT software after the firewall. Lovely.

There is one fly in the ointment: the Raspberry Pi turns out to make a rubbish router. Our 30 megabit internet connection is reduced to 3 megabits on its way through the Pi. I don’t know if it’s something to do with my configuration, or the release of OpenWRT (15.05-rc3) I’m using. When I’ve unpacked enough boxes to find another router, I’ll try that.

martinjonestechnology

What's going on in the workshop?

Category Archives: Projects

Sony WM-D6C Walkman Pro DC-DC converter repair

Quick-and-dirty partition resize with Acronis True Image

Good accuracy from a low cost Real Time Clock

The Euroquadruped, or the solution to wall wart Tetris

Garage door opener life extension

Cracking a password-protected PDF file

Systemd for Embedded Linux

Lattice FPGA programming adapter from the junk box

First steps with a Lattice iCE40 FPGA

Orange Internet and port forwarding, continued