Debugging in software vs electronics
Recently the PCB of our safety control unit arrived. This is a PCB we designed ourselves and then had the designs produced and assembled at our partner Eurocircuits. Of course I'm very excited about finally having the PCB I worked on designing for quite a while in my hands, but a big part of the work still remained. After all the processor on the safety control unit still had to be programmed and tested. While doing this I ran into some unexpected behaviour that had to be debugged. Since this is a PCB this involves debugging both the software written to the processor and the hardware on the PCB. I have a lot of experience with debugging software from my bachelor in Computer Science and my part-time job in software development, but my experience with debugging hardware is very limited. In this blog I will talk about some of the similarities and differences I noticed between debugging software and hardware.
The main similarity is that the main structure of the process is still the same and the same principles apply. First you start with some inputs for which you know the expected output. If it does not produce this output you start looking from the point where the input is given and move towards the output to see if in between the input and output you can find any unexpected behaviour. If you find any unexpected behaviour you figure out why this is happening and use this to resolve the bug by making some adjustments.
The differences lay mainly in how you measure the expected behaviour and how you resolve the bug. In software this tends to be a lot easier than in hardware.
When debugging software to see if the program is behaving as you expect, you can for example add a breakpoint in your program, this will then pause the program at the line you put the breakpoint and show you the state of the program at that point. When you're working with hardware you can't just pause the real world, if you want to measure some static behaviour you'll have to make sure yourself that the hardware stays in that state either by programming the processor in a certain way or by hooking up some external circuitry.
You also might not be able to easily measure everything you want since some parts of the circuit might not have places where you can hook up the measuring equipment. In software you don't encounter this problem often, since you can usually easily print some values during execution or add some breakpoint to the program. When debugging hardware you can't just pause the world for a while and you have to work with the access points you have, you might want to know what the voltage at a certain point is but have no easy way to measure it. Measuring dynamic processes can also be a lot harder, in software you could for example add a logger that prints the values you're interested in with a timestamp, giving you a quite precise idea of how the values change over time. With hardware we need special measuring equipment, like an oscilloscope for that. One part of the SCU I was having an issue with for example was a relay that had to be switched after a delay of around 200ms. To test this delay I had to hook up an oscillator we have, since this can show the voltage change over time quite precisely. The circuit did have some small issues with it but after making some adjustments I managed to get a delay that corresponds quite well with the one it was designed for. The test set up for this can be seen in Image 1. Image 2 shows the output the oscilloscope produces on the computer. The bottom part of the image shows the input signal to the circuit and the top part the output signal. We can see there is a delay of about 190ms between the two red lines, which start at the input signal going to high (bottom) and end at the output signal being 0V (top) and that this shows that the circuit now (roughly) has the delay it was designed for.
Finally hardware is harder to adapt than software. This both affects identifying bugs and resolving them. First for identifying, in hardware you can't just make some adjustments, recompile and see how this changes the behaviour. If you're lucky enough that the adjustments you need can be made easily to the hardware you have to either also be lucky that they can be made in a way that you can revert them afterwards without permanently altering the hardware or the alterations to the hardware should be ones that don't matter to you for other reasons (maybe it’s just a prototype board). Secondly, for resolving them, this also means that if you're making changes to the hardware that you cannot revert that you have to be absolutely certain your fix works before you apply it!
To conclude, while there are a lot of differences between hardware and software debugging which often make hardware debugging harder. I was quite happy to see that I could apply the same principles I learned in my Computer Science bachelor for debugging software to successfully debug hardware at Nova as well.