If you are a system developer, this article might be a worthwhile read. There are occasions when you run into problems while programming a board. Any problems with software or design systems are stressful, but when it has to do with having no test points it’s an added stress. Learn about a scenario like this in the article below.
Where, Oh Where, Are My Test Points!
As embedded system developers, we spend a lot of time trying to get our systems to work the way they are supposed to. So why are we not following simple best practices that can save us time, headaches, and help us deliver on time?
by: Jacob Beningo on October 19, 2017
For the umpteenth time in my career, I am debugging a prototype board that has exactly zero test points. I didn’t design this board, but have inherited it from a frantic colleague who is behind schedule and is having trouble communicating with an onboard SPI device. The first step in this troubleshooting endeavor is to simply take an oscilloscope or logic analyzer and check the signal lines to see if they are wiggling at all. Of course, the microcontroller pins are soldered under the chip, with no accessible vias or test points. The troublesome device offers no help at all with its pins also neatly tucked below. Where oh where are my test points!
When I talk with clients and colleagues about how much time they spend debugging their systems, I’m often given numbers that range from 20% to 50% with the occasional tongue in cheek response of 80%. As embedded system developers, we spend a lot of time trying to get our systems to work the way they are supposed to. So why are we so stubborn (or arrogant) to not follow simple best practices that can save us time, headaches, and help us deliver on time?
When it comes to test points, I’ve generally heard two arguments for not putting them on a board. First, the security experts recommend making their lives difficult by minimizing test points, access to JTAG, etc. The harder it is to get access to the MCU and the onboard software the better. This is a good recommendation, for production hardware, but every security expert I’ve talked with has always confided that no matter what someone does, they find their way around the board to get access to what they need anyway. Best case, the would-be hacker just gets annoyed because they have extra work to do. So, in the end, this recommendation is just a short-term stop gap that is just making the development teams life a living hell.
Second, putting test points or extra vias on the board costs extra money, and every good layout engineer knows that they should be minimizing costs. The problem with this argument is that it’s from the last century. Board costs are no longer dependent on how many holes have been drilled in them. The industry has become so commoditized that you can drill vias all over the place and the end cost increase is a few pennies, if there is a cost increase at all. (Board costs are now more dependent upon physical size and copper weighting.)
On the very first board I ever designed, back in 2002, the first painful lesson I learned was that in order to debug the hardware and software efficiently, every signal, yes, EVERY signal, needs to be easily accessible. Whether it’s through clamping onto a pin, having an exposed pad to solder a wire on, or my personal favorite, a via that I can solder a header onto. If a developer doesn’t have access to the signals and runs into problems, their system debugging turns into a time-consuming guessing game that….