Making the same mistake twice

We all make mistakes – after all, we’re only human.  The key thing is to learn from them.

I’ve made a few in my time.  Like when I improved my ZX81’s power supply by adding a linear regulator to drop the voltage so that the computer ran cooler.  I also decided to house this new power supply in a metal box which of course had to be earthed.  The other problem with the ZX81 was that the programs were loaded by tape and my machine was unreliable.  So I came up with the idea of using the speaker output from my hi-fi to improve the drive into the phones socket.  It looked good for about 40 seconds at which point one of the output transistors, which was now shorted to the earth via the new power supply box, went up in a puff of smoke.  Needless to say, I knew what had happened immediately and cursed my stupidity.

Although it was slightly less dramatic, years later I came across an odd problem with a customer board.  I said in my last post that it’s ideal to have a proper debugger where you can set breakpoints and so on.  However, we also used a debug application that connected via the serial port.  A bit like HyperTerminal but with a fancy front-end that gave you access to all of the chips registers and would allow you to navigate various the menu states without having to provide the key presses or infra-red buttons.

On this particular customer’s board, the serial debug interface was not working and according to the software engineers had never worked.  The odd thing is that the serial port appeared to be fine because the customer could use it to flash the code down to the board.  It wasn’t a big issue because the engineers to read the registers by looking at a dump of the memory map but it was definitely more convenient to have the register names rather than the memory addresses, so I wanted to find out why it wasn’t working.

A look at the customer’s schematic revealed the issue.  The hardware designer, instead of powering the serial port from the supply, had powered it from a GPIO pin of the microcontroller.  Presumably he wanted to use the micro to disable or enable the serial interface depending on the state of the GPIO pin.  The result was that there was just enough current to be able to flash code down to the board but not enough to handle the different baud rate for debugging.

I cut the track and put a wire straight to the supply and was then able to both flash the code and run the debug interface.

The hardware engineer moved companies, to their largest competitor, where he designed a board with another of our chips.  When I came to debug that board, yes you’ve guessed it, I could flash code but the serial debug interface did not work.  He had made the same mistake twice!

Needless to say, when he asked for a recommendation on LinkedIn, I ignored the request.

Leave a Reply

Your email address will not be published.