SmartParallel: troubleshooting with logic analyser and scope

Well, it does seem that the problem I’ve been having with the SmartParallel board is indeed that horror of horrors – the intermittent fault.

Or perhaps something weirder. This is some kind of quantum device – it works only when being observed.

Setting up a server

The SmartParallel was working perfectly for a few days. Then I didn’t use it for a couple of days while messing around with setting up a server for it. I’m using a Raspberry Pi, of course, but which type? My first instinct was to use up one of the (rather too many) older Pi boards I have knocking about. I even went as far as building a Raspberry Pi Model B with the latest Buster Lite image. But I found that the wireless interface (a Netgear dongle) wouldn’t stay up reliably.

So I’ve prepared two more boards with pretty much identical configurations and will see how they compare. One is a Pi 3 and the other a Pi Zero W. Aside from my normal setup for the Raspberry Pi, each also has Docker installed which I’ll be using to run the web server. Currently, this is configured fine on the Pi 3. On the Zero, Docker is installed but I haven’t tried running the web server yet.

Nothin’ happening

The Pi 3 was printing to the Epson MX-80 just fine before. But when I tried the Pi Zero, nothing got printed. As with the earlier problem, the Go program (spprintfile) on the Pi thought it was printing – it was getting the requisite serial messages back from the SmartParallel. And, in fact, the SmartParallel also thought it was working fine, as far as I could tell. The Busy LED, which is controlled by the printer, would flash briefly in response to what appeared to be text being sent.

I switched back to the (previously working) Pi 3 and found exactly the same situation. Dammit!

Obviously it was time to start probing.

Strobing effects

It’s worth briefly recapping how printing works on a parallel interface. The host machine (in this case, the SmartParallel) sets up a byte on the eight Data lines. It then takes the /Strobe line low for a brief pulse. The printer responds by taking the Busy line high while it ingests the byte. Once it has done that, it briefly pulses the /Ack line low and then lets the Busy line go low again. (Not all host interfaces/software pay attention to the /Ack signal, but the SmartParallel does.)

I’d started to have my doubts about the /Strobe signal. The behaviour I’d been seeing – with data being sent but nothing getting printed – would be largely explained if, somehow, the /Strobe signal wasn’t functioning somehow. (Actually, this doesn’t explain why the Busy light flashes, but I’d overlooked that.)

I set up the oscilloscope and probed the /Strobe signal while printing. To be specific, I was probing the buffered signal that emerges from the 74LV541 buffer chip – so this is the most direct connection to the printer. And I saw something strange. (Click on any of these images to see a larger version.)

Can you see how the /Strobe line seems to dip to 0V briefly but is then held at a middling voltage for a period. A closer look confirms that the line is being pulled fully low as required.

It’s low for about 1µs, which is the length of the /Strobe pulse I defined in the ATMEGA328PB code on the SmartParallel. But the fact it’s not returning to 5V immediately is worrisome.

On the SmartParallel, the /Strobe line is pulled high with a 10KΩ resistor on the input (microcontroller) side of the buffer chip. But what’s holding it at that intermediate voltage? Sometimes it’s held there for some time.

In the case above, it’s at the voltage for nearly 20ms. I know the printer also pulls the /Strobe line high by default, so I’m assuming it’s not the printer doing this.

Odd behaviour

If that wasn’t weird enough, while I was probing the /Strobe line, the printer started printing. It wasn’t perfect – it would miss out characters – but at least it was doing something.

This is exactly what happened before. And so, as before, I rechecked my soldering. And yes, the soldering of a few of the pads on the 74LV541 could have been tidier. The messy bits included the /Strobe line.

As a matter of course, I always check continuity between adjacent legs of ICs after soldering, to ensure there are no dead shorts. By perhaps there was some connection between pins at too high a resistance to be detected with a continuity test, but low enough to make things squinky.

So I touched up the soldering. At the same time, I had a brainwave. I flipped the SmartParallel board over and soldered wires to the pins of the DB25 connector – at least to the /Strobe, /Ack and Busy pins and also to data pins D0-D6. (I didn’t bother with D7 because this rarely, if ever, gets set.)

Now I can test what’s actually being sent to the printer. I hooked up the logic analyser to the /Strobe, /Ack and Busy lines and data lines D0-D4 (it’s only an eight-channel analyser).

What I saw was what I expected to see. Why? Because the bloody thing started working perfectly again.

This sequence of events is identical to what I had last time: nothing gets printed; then, while probing, most of it gets printed, but with missing characters and lines; then after a bit of touch-up with the soldering, it all works fine.

Highly logical

First, let’s take a look at the logic analyser’s output, because it’s pretty.

Actually, this is not the first capture I made. The first one showed that many of the /Strobe pulses were missing. “Aha!” I thought, until I realised that the Busy and /Ack signals were present, which meant the printer must have been responding to /Strobe pulses.

The reality, of course, was that I was capturing at too low a bit rate – 100KHz, if I remember correctly. I eventually boosted this to 4MHz and the /Strobe pulses were all present and correct.

I have to say that the logic analyser is proving to be an invaluable tool and I wish I’d got around to using it sooner. Being able to see the state of up to eight signals over quite a long period is something an oscilloscope – or, at least, any kind of oscilloscope I can afford – just can’t do. That said, a logic analyser has its own limitations. It would have missed – or possibly misrepresented – that odd signal I was getting on the /Strobe signal, with the signal remaining at that intermediate level.

Talking of which, after my re-soldering efforts, that effect seems to have gone away. Here’s the /Strobe pulse now.

That’s exactly as it should be.

The logic analyser captures at least allowed me to confirm that things were working as they should. For example, here’s a sequence of characters being sent to the printer.

I haven’t included the data lines. The signals you can see are, from top to bottom, /Strobe, Busy, /Ack. Let’s take a closer look.

Note how quickly the Busy line goes high when the /Strobe is sent.

Also, you can just about see how the /Ack pulse is sent by the printer before it drops the Busy signal. On the right, we zoom in even closer to see this in action.

At the beginning of the sequence, the Busy line goes high before the /Strobe pulse is finished. This suggests the length of the /Strobe pulse is far from critical. I even got to wondering if we could get more reliable operation if the length of the pulse is increased. But I don’t think the /Strobe pulse is the problem – after all, even when the problem was at its worst, with no printing taking place, the Busy light would still flash, confirming that the printer was responding to a /Strobe signal.

The Epson manual stipulates a minimum /Strobe pulse of 0.5µs, and the SmartParallel is currently using 1µs.

Interestingly, this capture shows the Busy line going high about half-way through the /Strobe pulse, so I guess Epson wasn’t kidding about its timings. I don’t know why I’m impressed by that, but I am.

However, while this is all very interesting, and I did have fun (as always) playing with the logic analyser and the scope, where does this leave us?

Working, for now

This morning, having left the printer, SmartParallel and Raspberry Pi powered down overnight, I fired it all up again and tried printing. Worked a treat.

I’d like to think it’s fixed, but I’ve now gone through this cycle of ‘not working – partly working – working’ twice now. I’m going to leave the SmartParallel wired up to the logic analyser, ready to test at a moment’s notice. But I’m now in the stupid position of hoping that it will stop working so that I can test it. Selah.

PS. Somebody asked me a while back if I could dump the ROMs from the Epson (sorry, can’t remember your name and I’ve somehow lost the message). It has three 2716 EPROMS which, I’m told, means it’s fitted with the Graftrax firmware. I’ve now done this and you can find the file on the new Resources page.