Soldering
Once your project PCB has been fabricated and checked carefully to ensure that all pads and tracks are intact and properly etched, do the construction a step at a time and check everything as you go. Using a multimeter, do a continuity test between the ground pads and the power pin on the power connector to make sure there isn't a short between your power rails. Nothing lets smoke out faster than a power short.
Solder fumes are toxic and prolonged exposure to them is bad for your health. When soldering, ensure that your work area is well ventilated. It may also be worth investing in a fume extractor. The key to soldering well is to control the heat and the amount of solder that flows onto component pins. Too much heat can damage a component (especially sensitive integrated circuits), and can overheat the solder as well. Read the datasheets to determine the maximum temperature (and duration) that the components can take, and ensure that your soldering does not exceed this. Variable-temperature irons allow to you set the temperature, thereby avoiding overheating. The tip of your soldering iron should be thin, allowing you to do fine work. An old-style iron with a large, bulky tip (intended for electrical work) is not appropriate for soldering electronics.
Solder fumes are toxic and prolonged exposure to them is bad for your health. When soldering, ensure that your work area is well ventilated. It may also be worth investing in a fume extractor. The key to soldering well is to control the heat and the amount of solder that flows onto component pins. Too much heat can damage a component (especially sensitive integrated circuits), and can overheat the solder as well. Read the datasheets to determine the maximum temperature (and duration) that the components can take, and ensure that your soldering does not exceed this. Variable-temperature irons allow to you set the temperature, thereby avoiding overheating. The tip of your soldering iron should be thin, allowing you to do fine work. An old-style iron with a large, bulky tip (intended for electrical work) is not appropriate for soldering electronics.
|
|
Whenever you solder your PCB, make sure that it is not powered! The tip of a soldering iron is grounded and touching this to a pad with volts on it is not a good idea!
Similarly, when inserting or removing socketed components, ensure that the system is powered down. Most semiconductors do not appreciate being plugged into a live system. |
|
|
When soldering, there should be enough solder to make a good contact, but not so much that it bulges up, or worse, shorts a neighboring pin. Common mistakes when soldering are to heat the component pin for several seconds before applying solder (causing the component to become too hot), or to apply the solder directly to the iron and then dab the molten solder onto the pin.
|
|
When soldering through-hole components (such as DIP-packaged chips or connectors), place the component into its hole and ensure that it is mounted correctly and sitting flat. To begin, solder one pin only, then check that the component is still seated correctly before doing the remaining pins. With the iron in one hand, and a thin strand of solder in the other, bring the two together such that they meet at the pin to be soldered. Within a second, the solder will flow around the pin and you will have a good join. As soon as the solder begins to flow, remove both the iron tip and the solder strand. If you are using DIP chips, rather than soldering the chip directly into the circuit, solder a DIP socket instead. This allows you to easily remove/replace the chip is you have to, without the inconvenience (and frustration) of desoldering. Machined sockets, while they cost more, are more reliable and will last longer.
|
Soldering surface-mount components requires a different procedure. If you’re using a rework station, you will need to use solder paste. This is sold in a large syringe. Solder paste easily dries out inside the syringe, so ensure that you seal the end when it is not in use. Before soldering a surface-mount chip, place a thin squirt of solder paste along each row of pads on the PCB. If there is too much paste, it can flow under the chip and create a short, so keep the application light. You can always add a small quantity later.
|
|
Place the chip onto its PCB pads, and ensure that it is lined up correctly, then use the rework station to apply heated air. Too much airflow will either shift the chip off its correct orientation, or worse, blow solder paste underneath. Since solder paste is electrically conductive, this is not a good thing. Too little heat will result in poorly soldered joints, whereas too much heat can easily overheat and damage the chip. It is something of an art to get it just right and so it’s best to do considerable practice before tackling the real thing.
Surface-mount chips can also be soldered using a standard iron, although it’s not recommended for really finely-spaced chip pins. Unlike the technique with the rework station, solder paste is applied after the chip is in place. To begin, before putting the chip on the PCB, use the iron and either strand solder or solder paste to place a small dab of solder directly onto one of the pads where the chip is to be mounted. Place the chip in position, aligning it carefully, and then use the iron to heat the pin resting on the solder dab. The dab will melt, and fix the chip in place. Check the alignment again to ensure that the chip did not shift. If it did, reheat the pin again, and carefully shift the chip as appropriate. Once you are happy with the alignment, place a thin squirt of solder paste down each row of pins and as far from the edge of the chip as possible. Too much paste will flow between the pins creating shorts, so keep it light. Gently and quickly run the tip of the soldering iron down each row of pins. The solder paste will melt and flow as you go, and bond the chip to the PCB.
Solder is a metal alloy and incorporates a flux to assist flow. When heating the solder, it is common for the flux to separate and flow out onto the surrounding PCB, leaving a thin brown residue. Excess flux can be removed using special solvents, available from most electronics hobby stores and suppliers. Flux removers can be nasty stuff so keep them away from skin and plastics, and use in a well-ventilated work area. Flux residue is removed for cosmetic reasons only, making your circuit boards look more professional for your customers. However, as it is for appearances only, and since flux solvents are not good for either you or the environment, if you can avoid using them, please do so.
Solder is a metal alloy and incorporates a flux to assist flow. When heating the solder, it is common for the flux to separate and flow out onto the surrounding PCB, leaving a thin brown residue. Excess flux can be removed using special solvents, available from most electronics hobby stores and suppliers. Flux removers can be nasty stuff so keep them away from skin and plastics, and use in a well-ventilated work area. Flux residue is removed for cosmetic reasons only, making your circuit boards look more professional for your customers. However, as it is for appearances only, and since flux solvents are not good for either you or the environment, if you can avoid using them, please do so.
Start construction by soldering in the power connector, voltage regulator and its support components, including the “power” LED if you’ve included one in your design.
Once you’ve soldered in the components needed for the power supply, power up the board and check that this is operational. Also check that you have power on every pad on the board where you expect power to be, and check the ground pads to make sure that there is no power where you expect no power to be. If your PCB is intended to be used with an embedded system, such as a Scamp, make sure that system is not connected at this stage.
Next, solder in the power-decoupling capacitors for the chips. If there's an oscillator, check its operation with an oscilloscope. Does it have the right waveform on its output?
Once you have enough hardware built and have checked voltages are nominal, then power it down and connect it to your embedded system. If you're using a Scamp, you can use Forth to interactively assist you with the debugging.
Once you’ve soldered in the components needed for the power supply, power up the board and check that this is operational. Also check that you have power on every pad on the board where you expect power to be, and check the ground pads to make sure that there is no power where you expect no power to be. If your PCB is intended to be used with an embedded system, such as a Scamp, make sure that system is not connected at this stage.
Next, solder in the power-decoupling capacitors for the chips. If there's an oscillator, check its operation with an oscilloscope. Does it have the right waveform on its output?
Once you have enough hardware built and have checked voltages are nominal, then power it down and connect it to your embedded system. If you're using a Scamp, you can use Forth to interactively assist you with the debugging.
Thoughts on Debugging
When designing your system and laying out the PCB, remember that you will have to debug it. So, design it with debugging in mind. Include one or more status LEDs. These are invaluable for debugging embedded hardware.
You are also going to need to look at signals with an oscilloscope, so include a ground pin on your circuit board onto which you can clip. Also, make sure that you will be able to get an oscilloscope probe to every circuit trace on the board to examine what’s going on. If you can’t get to a track, you can’t look to see that there’s no problem with that particular signal.
So even at the design stage, think carefully about how you can test the subsystems and isolate problems, and put the necessary support into your design.
Debugging is as much an art as it is a science. You can load a workbench to breaking point with all sorts of expensive test equipment, yet without a logical approach and a clear mind, elusive bugs will never be found. Conversely, by “right thinking,” the strangest of bugs can be isolated with a minimum of tools. While it is true that the more complex the system under test, the harder it is to nail down a fault through detection, it is also true that the most advanced and useful debugging tool you have at your disposal is your own brain. Therefore, learning to debug is learning to think carefully and clearly.
Debugging hardware can be a lot trickier than debugging software. With code, you can always put in some diagnostics to inspect the execution. That’s not to say that debugging software is trivial - far from it. But with hardware, it is often either a case of it all works, or nothing works. Software has the advantage of being able to be brought into operation gracefully. For hardware, you need to have an awful lot working right from the start.
The essence of debugging is establishing what works and what doesn’t work. As your designs grow in complexity, finding hardware and design faults can become quite an involved problem.
For example, an embedded system may not be outputting characters through its serial port. Why? Perhaps it’s a bug in the code. Maybe there’s a cable fault. Maybe the interface chip has been zapped by an electrostatic discharge. It might be that there is a timing mismatch, or a voltage-level problem. Perhaps the processor itself is not coming out of reset, and therefore not executing code at all. If so, maybe it’s the power-on reset circuit failing to kick in, or the brown-out detector kicking in when it shouldn’t. Maybe a data line between the processor and the serial chip is not connected, perhaps due to a manufacturing fault with the PCB. Or maybe it wasn’t soldered correctly. Perhaps your voltage regulator isn’t operating properly, or maybe you’ve got a faulty power supply. And those are just the obvious causes that spring to mind. There are a thousand others lurking, with big teeth and a nasty disposition.
For any one problem, there is a multitude of possible causes. Debugging is therefore about isolating a fault, and this is best done by a “20 questions” approach. Use divide and conquer to solve the problem.
Let’s take the example of the faulty serial port problem above. You discover the problem when you first try to test the serial port. Your simple test code fails to output a character. Is the problem in software or hardware? If hardware, is the problem with the cable, the serial chip(s), or a more fundamental problem with the core system? Check the cable and the terminal (or host PC) first. Disconnect the cable from the embedded computer, and with a piece of metal (a screwdriver blade will do), short out pins two and three (Rx and Tx) on the cable connector. Now type something on the terminal (or the terminal software on the PC). What comes out of the terminal should echo back through the short and appear on the screen. That will tell you whether there is a cable fault and whether the terminal is setup correctly.
If that works, then the problems lie in your embedded system. Replace your serial test code with code that does something else that is simpler (like waggle a digital I/O line, or flash a LED). That simple action will tell you volumes. (Archimedes once said, “Give me a lever long enough and I will move the world.” Well, give me a status LED and enough time, and I'll debug the world too!) It will tell you whether your processor is executing code correctly, which in turn shows that the processor and ROM (if a separate chip) have power and are communicating correctly. It shows that the reset circuit, brown-out detector, oscillator, voltage regulator, address decoder and other support logic are ok. If any of these are failing, then the processor will not be executing code, and therefore that I/O line will not waggle or that LED will not flash. By that simple test, you have ruled out a plethora of possible faults.
Otherwise you know to look elsewhere for the problem, such as checking the oscillator, reset or voltage regulator for correct operation. Divide and conquer. If the test passed, then the fault lies with the serial chip. Most serial chips include some digital I/O that can be manually set (such as RTS). Write some test code that does this. This simple test will show whether or not you can talk to the chip. If the test passes, you know to look at either your character-output software, or the RS-232 driver. If the test fails, then the problem lies in talking to the chip. Use an oscilloscope to check the chip select and other control signals going to the serial chip. Are they active? Are they reasonable? Write some software that continually “jams” a byte at a register in the serial chip. While meaningless to the serial chip, a continuous write of the same number allows you to observe the bus activity.
You will expect to see the above bit pattern on the data bus (and importantly on the appropriate pins of the serial chip) at the same time as the chip select and write enable are asserted.
This will enable to you to locate a problem with the processor writing to the serial chip. Alternatively, if you can demonstrate that you can write to the chip correctly, then the problem lies either in the software, or between the serial chip and the serial connector. By using the divide and conquer approach, you can isolate where a problem lies. Devise tests to prove each aspect of system operation.
Often you will be faced with a bug that makes no sense. Something should be working, and it is not. Everything you check seems right, but the total system just isn’t working. It can be very perplexing. You have made a common error - you have made an assumption. Somewhere, even though you may not be consciously aware of it, you have assumed that some little detail is correct, when in fact it is not. This is the hardest obstacle to overcome. When you say to yourself, “It should be working, but it isn’t! It doesn’t make sense!” then say to yourself, “There is still something I haven’t checked.” Go looking for it. If you can’t find it, then you haven’t looked hard enough.
You are also going to need to look at signals with an oscilloscope, so include a ground pin on your circuit board onto which you can clip. Also, make sure that you will be able to get an oscilloscope probe to every circuit trace on the board to examine what’s going on. If you can’t get to a track, you can’t look to see that there’s no problem with that particular signal.
So even at the design stage, think carefully about how you can test the subsystems and isolate problems, and put the necessary support into your design.
Debugging is as much an art as it is a science. You can load a workbench to breaking point with all sorts of expensive test equipment, yet without a logical approach and a clear mind, elusive bugs will never be found. Conversely, by “right thinking,” the strangest of bugs can be isolated with a minimum of tools. While it is true that the more complex the system under test, the harder it is to nail down a fault through detection, it is also true that the most advanced and useful debugging tool you have at your disposal is your own brain. Therefore, learning to debug is learning to think carefully and clearly.
Debugging hardware can be a lot trickier than debugging software. With code, you can always put in some diagnostics to inspect the execution. That’s not to say that debugging software is trivial - far from it. But with hardware, it is often either a case of it all works, or nothing works. Software has the advantage of being able to be brought into operation gracefully. For hardware, you need to have an awful lot working right from the start.
The essence of debugging is establishing what works and what doesn’t work. As your designs grow in complexity, finding hardware and design faults can become quite an involved problem.
For example, an embedded system may not be outputting characters through its serial port. Why? Perhaps it’s a bug in the code. Maybe there’s a cable fault. Maybe the interface chip has been zapped by an electrostatic discharge. It might be that there is a timing mismatch, or a voltage-level problem. Perhaps the processor itself is not coming out of reset, and therefore not executing code at all. If so, maybe it’s the power-on reset circuit failing to kick in, or the brown-out detector kicking in when it shouldn’t. Maybe a data line between the processor and the serial chip is not connected, perhaps due to a manufacturing fault with the PCB. Or maybe it wasn’t soldered correctly. Perhaps your voltage regulator isn’t operating properly, or maybe you’ve got a faulty power supply. And those are just the obvious causes that spring to mind. There are a thousand others lurking, with big teeth and a nasty disposition.
For any one problem, there is a multitude of possible causes. Debugging is therefore about isolating a fault, and this is best done by a “20 questions” approach. Use divide and conquer to solve the problem.
Let’s take the example of the faulty serial port problem above. You discover the problem when you first try to test the serial port. Your simple test code fails to output a character. Is the problem in software or hardware? If hardware, is the problem with the cable, the serial chip(s), or a more fundamental problem with the core system? Check the cable and the terminal (or host PC) first. Disconnect the cable from the embedded computer, and with a piece of metal (a screwdriver blade will do), short out pins two and three (Rx and Tx) on the cable connector. Now type something on the terminal (or the terminal software on the PC). What comes out of the terminal should echo back through the short and appear on the screen. That will tell you whether there is a cable fault and whether the terminal is setup correctly.
If that works, then the problems lie in your embedded system. Replace your serial test code with code that does something else that is simpler (like waggle a digital I/O line, or flash a LED). That simple action will tell you volumes. (Archimedes once said, “Give me a lever long enough and I will move the world.” Well, give me a status LED and enough time, and I'll debug the world too!) It will tell you whether your processor is executing code correctly, which in turn shows that the processor and ROM (if a separate chip) have power and are communicating correctly. It shows that the reset circuit, brown-out detector, oscillator, voltage regulator, address decoder and other support logic are ok. If any of these are failing, then the processor will not be executing code, and therefore that I/O line will not waggle or that LED will not flash. By that simple test, you have ruled out a plethora of possible faults.
Otherwise you know to look elsewhere for the problem, such as checking the oscillator, reset or voltage regulator for correct operation. Divide and conquer. If the test passed, then the fault lies with the serial chip. Most serial chips include some digital I/O that can be manually set (such as RTS). Write some test code that does this. This simple test will show whether or not you can talk to the chip. If the test passes, you know to look at either your character-output software, or the RS-232 driver. If the test fails, then the problem lies in talking to the chip. Use an oscilloscope to check the chip select and other control signals going to the serial chip. Are they active? Are they reasonable? Write some software that continually “jams” a byte at a register in the serial chip. While meaningless to the serial chip, a continuous write of the same number allows you to observe the bus activity.
You will expect to see the above bit pattern on the data bus (and importantly on the appropriate pins of the serial chip) at the same time as the chip select and write enable are asserted.
This will enable to you to locate a problem with the processor writing to the serial chip. Alternatively, if you can demonstrate that you can write to the chip correctly, then the problem lies either in the software, or between the serial chip and the serial connector. By using the divide and conquer approach, you can isolate where a problem lies. Devise tests to prove each aspect of system operation.
Often you will be faced with a bug that makes no sense. Something should be working, and it is not. Everything you check seems right, but the total system just isn’t working. It can be very perplexing. You have made a common error - you have made an assumption. Somewhere, even though you may not be consciously aware of it, you have assumed that some little detail is correct, when in fact it is not. This is the hardest obstacle to overcome. When you say to yourself, “It should be working, but it isn’t! It doesn’t make sense!” then say to yourself, “There is still something I haven’t checked.” Go looking for it. If you can’t find it, then you haven’t looked hard enough.