Design for Test in Embedded Development

Just like a custom PCB will need testing and evaluation, your embedded system will also need to be tested, both at the hardware level and embedded application level. Embedded systems require testing at multiple levels, starting from the chips during semiconductor fabrication, and ending at the PCB assembly via a battery of tests. An embedded software or firmware application also needs testing via a hardware interface, but many users do not approach this in the most efficient manner.

Hardware designers will often approach embedded application testing in the same way they will approach their circuit testing by probing with a multimeter or scope probe. Instead of poking around in the dark with multimeters and scopes, follow these tips for embedded systems design that enable testing and monitoring in a stress-free way.

How Hardware Engineers Usually Approach Embedded Systems Testing

Any board designer should know, an embedded system involves a complex processor and set of peripherals, each of which can seem like a black box. You won't know what's happening inside your embedded application or the hardware response to your application unless you build monitoring abilities into the hardware and your embedded software/firmware. Many PCB designers only approach this from the hardware side because that's what works everywhere else. This usually means copious use of following:

• Test points connected to every possible indicator pin on processors and peripherals
• Extra pin headers, which can double as test points or connections to external modules
• Indicator LED circuits that are driven by logic states or power circuits

By the time you hook up all of your probes, floating wires, and external modules, the PCB starts to look a lot like a creation from Dr. Frankenstein. If your goal is to test an embedded system’s software or firmware functionality as it relates to hardware, there are better ways to streamline your prototype design and the data capture process. A streamlined design will reduce the number of required flying lead and probe connections so that you only monitor what is absolutely necessary in external measurement units. The rest can be monitored in software first, rather than probing with hardware.

A Software-First Approach

The first step in a software-first approach is to have an interface between your embedded system prototype and a computer for data capture.

Monitoring an embedded system prototype during testing means that you need to have a connection back to a computer, which will allow monitoring of the application as it executes key functions. The easiest way to do this is with a serial connection to your computer. In the past this would involve a RS-232 or RS-485 connection over a DB9 connector. Today the simplest method is to connect to a USB port and monitor the system over a serial interface.

The other option is a flying lead connection to a DAQ module, such as the module shown below. These modules can be controlled in a test and measurement application like LabVIEW, or the DAQ vendor may have proprietary software that will monitor the inputs. The input connections could be made via ribbon cable, flying leads, or a combination of both, and the DAQ then connects back to a computer via USB.

DAQ module for data capture in desktop computer or server.

Next, the code you deploy on the prototype system needs to provide the right data back to your host computer. A bit of planning is needed at the design stage to do this successfully.

Plan Ahead For Connections

Which connections will you need in order to capture data from your prototype? As was mentioned above, this could involve a serial connection to your computer, or a DAQ module that grabs data from flying leads or ribbon cables. To get data through these connections, you can use a simple board architecture:

All these options give you access to data and indicator pins on your chips. However, for important status indicators, there is more work that needs to be done in your embedded application.

Error Handling in Your Code

The above list only shows ways to break out the GPIOs and important indicator pins on ASICs, but it doesn't tell you anything about your actual application. The easiest way to see when there is a problem in your embedded application is to build in error handling and status indicators in your key functions. Success/failure/error flags that print directly on screen via a terminal app help users spot problems and minimize debug time for an embedded application.

For example, in MicroPython, an error handler would be implemented with a simple stdout function:

Now you will have a textual description for any error that arises in your application. Error handlers should be descriptive, stating specifically which part of the function passed or failed. This allows you to track the progress of your application through each logical step, this way errors won't have to be tracked down manually or emulated in order to debug an application. When you have a terminal option listed above alongside indicator measurements, you'll be able to see exactly when an error occurs and how it coincides with the hardware functionality.

The Allegro X Design Platform offers an advanced PCB toolset and simulation options for systems analysis. Only Cadence offers a comprehensive set of circuit, IC, and PCB design tools for any application and any level of complexity.