Read Your Technical Documentation (EE Tip #145)

Last year we had a problem that showed up only after we started making the product in 1,000-piece runs. The problem was that some builds of the system took a very long time to power up. We had built about 10 prototypes, tested the design over thousands of power ups, and it tested just fine (thanks to POC-IT). Then the 1,000-piece run uncovered about a half-dozen units that had variable power-up times—ranging from a few seconds to more than an hour! Replacing the watchdog chip that controlled the RESET line to an ARM9 processor fixed the problem.

But why did these half dozen fail?

Many hours into the analysis we discovered that the RESET line out of the watchdog chip on the failed units would pulse but stay low for long periods of time. A shot of cold air instantly caused the chip to release the RESET. Was it a faulty chip lot? Nope. Upon a closer read of the documentation, we found that you cannot have a pull-up resister on the RESET line. For years we always had pull-ups on RESET lines. We’d missed that in the documentation.

Like it or not, we have to pour over the documentation of the chips and software library calls we use. We have to digest the content carefully. We cannot rely on what is intuitive.

Finally, and this is much more necessary than in years past, we have to pour over the errata sheets. And we need to do it before we commit the design. A number of years ago, a customer designed a major new product line around an Atmel ARM9. This ARM9 had the capability of directly addressing NOR memory up to 128 MB. Except for the fact that the errata said that due to a bug it could only address 16 MB. Ouch! Later we had problems with the I2C bus in the same chip. At times, the bus would lock up and nothing except a power cycle would unlock it. Enter the errata. Under some unmentioned conditions the I2C state machine can lock up. Ouch! In this case, we were able to use a bit-bang algorithm rather than the built-in I2C—but obviously at the cost of money, scheduling, and real time.—Bob Japenga, CC25, 2013

Embedded SOM with Linux-Based RTOS

National Instruments has introduced an embedded system-on-module (SOM) development board with integrated Linux-based real-time operating system (RTOS).NIsom

Processing power in the 2” x 3” SOM comes from a Xilinx Zync-7020 all programmable SOC running a dual core ARM Cortex-A9 at 667 MHz. A built-in, low-power Artix-7 FPGA offers 160 single-ended I/Os and Its dedicated processor I/O include Gigabit Ethernet USB 2.0 host, USB 2.0 host/device, SDHC, RS-232, and Tx/Rx. The SOM’s power requirements are typically 3 to 5 W.

The SOM integrates a validated board support package (BSP) and device drivers together with the National Instruments Linux real-time OS. The SOM board is supplied with a full suite of middleware for developing an embedded OS, custom software drivers, and other common software components.

The LabVIEW FPGA graphical development platform eliminates the need for expertise in the design approach using a hardware description language.

[Via Elektor]


New DSP “Lab-in-a-Box” for ARM-Based Audio Systems

Cambridge, UK-based, ARM and its partners will start shipping a DSP “Lab-in-a-Box” (LiB) to universities worldwide to help boost practical skills development and the creation of new ARM-based audio systems. This will include products such as high-definition home media and voice-controlled home automation systems. The LiB kits contain ARM Cortex-M4-based microcontroller boards by STMicroelectronics and audio cards from Wolfson Microelectronics and Farnell element14.ARMDSPLiBWeb

As the centerpiece of the ARM University Program, LiB packages offer ARM-based technology and high-quality teaching and training materials that support electronics and computer engineering courses. DSP courses have traditionally used software simulation packages, or hands-on labs using relatively expensive development kits costing around $300 per student. By comparison, this new DSP LiB will cost around $50 and will allow students to practice theory with advanced hardware sourced from widely-available products.

“Our Lab-in-a-Box offerings are proving hugely popular in universities because of the low-cost access to state-of-the-art technology,” said Khaled Benkrid, manager of the Worldwide University Program, ARM. “The DSP kits, powered by ARM Cortex-M4-based processors, enable high performance yet energy-efficient digital signal processing at a very affordable price. We expect to see them being used by students to create commercially-viable audio applications and it’s another great example of our partnership supporting engineers in training and beyond.”

The DSP LiB will begin shipping to universities in July 2014. It is the latest in a series of initiatives led by ARM which span multiple academic topics including embedded systems design, programming and SoC design. The DSP kits will also be offered to developers outside academia at a later date.


Client Profile: ARM, Ltd.

ARM, Ltd.

ARM, Ltd.
110 Fulbourn Road
Cambridge, GB-CB1 9NJ,
Great Britain


Embedded Products/Services: The ARM tools range offers two software development families that provide you with all the necessary tools for every stage of your software development workflow.

ARM Development Studio 5 (DS-5) provides best-in-class tools for a broad range of ARM processor-based platforms, including application processors and multicore SoCs. Find out more by visiting

Keil MDK-ARM is a complete software development toolkit for ARM processor-based microcontrollers. It is the right choice for embedded applications based on the ARM Cortex-M series, ARM7, ARM9, and Cortex-R4 processors. To find out more, visit

Product Information: The MDK-ARM is a complete software development environment for Cortex-M, Cortex-R4, ARM7, and ARM9 processor-based devices. MDK-ARM is specifically designed for microcontroller applications. It is easy to learn and use, yet powerful enough for the most demanding embedded applications.

The MDK-ARM is available in four editions: MDK-Lite, MDK-Basic, MDK-Standard, and MDK-Professional. All editions provide a complete C/C++ development environment and MDK-Professional includes extensive middleware libraries.

The Future of Data Acquisition Technology

Maurizio Di Paolo Emilio

Maurizio Di Paolo Emilio

By Maurizio Di Paolo Emilio

Data acquisition is a necessity, which is why data acquisition systems and software applications are essential tools in a variety of fields. For instance, research scientists rely on data acquisition tools for testing and measuring their laboratory-based projects. Therefore, as a data acquisition system designer, you must have an in-depth understanding of each part of the systems and programs you create.

I mainly design data acquisition software for physics-related experiments and industrial applications. Today’s complicated physics experiments require highly complex data acquisition systems and software that are capable of managing large amounts of information. Many of the systems require high-speed connections and digital recording. And they must be reconfigurable. Signals that are hard to characterize and analyze with a real-time display are evaluated in terms of high frequencies, large dynamic range, and gradual changes.

Data acquisition software is typically available in a text-based user interface (TUI) that comprises an ASCII configuration file and a graphic user interface (GUI), which are generally available with any web browser. Both interfaces enable data acquisition system management and customization, and you don’t need to recompile the sources. This means even inexperienced programmers can have full acquisition control.

Well-designed data acquisition and control software should be able to quickly recover from instrumentation failures and power outages without losing any data. Data acquisition software must provide a high-level language for algorithm design. Moreover, it requires data-archiving capability for verifying data integrity.

You have many data acquisition software options. An example is programmable software that uses a language such as C. Other software and data acquisition software packages enable you to design the custom instrumentation suited for specific applications (e.g., National Instruments’s LabVIEW and MathWorks’s MATLAB).

In addition to data acquisition software design, I’ve also been developing embedded data acquisition systems with open-source software to manage user-developed applications. The idea is to have credit-card-sized embedded data acquisition systems managing industrial systems using open-source software written in C. I’m using an ARM processor that will give me the ability to add small boards for specific applications (e.g., a board to manage data transmission via Wi-Fi or GSM).

A data acquisition system’s complexity tends to increase with the number of physical properties it must measure. Resolution and accuracy requirements also affect a system’s complexity. To eliminate cabling and provide for more modularity, you can combine data acquisition capabilities and signal conditioning in one device.

Recent developments in the field of fiber-optic communications have shown longer data acquisition transmission distances can cause errors. Electrical isolation is also an important topic. The goal is to eliminate ground loops (common problems with single-ended measurements) in terms of accuracy and protection from voltage spikes.

During the last year, some new technological developments have proven beneficial to the overall efficacy of data acquisition applications. For instance, advances in USB technology have made data acquisition and storage simpler and more efficient than ever (think “plug and play”). Advances in wireless technology have also made data transmission faster and more secure. This means improved data acquisition system and software technologies will also figure prominently in smartphone design and usage.

If you look to the future, consumer demand for mobile computing systems will only increase, and this will require tablet computers to feature improved data acquisition and storage capabilities. Having the ability to transmit, receive, and store larger amounts of data with tablets will become increasingly important to consumers as time goes on. There are three main things to consider when creating a data acquisition-related application for a tablet. Hardware connectivity: Tablets have few control options (e.g., Wi-Fi and Bluetooth). Program language support: Many tablets support Android apps created in Java. Device driver availability: Device drivers permit a high-level mode to easily and reliably execute a data acquisition board’s functionality. C and LabVIEW are not supported by Android or Apple’s iOS. USB, a common DAQ bus, is available in a set of tablets. In the other case, an adapter is required. In these instances, moving a possible data acquisition system to a tablet requires extra attention.

For all of the aforementioned reasons, I think field-programmable arrays (FPGAs) will figure prominently in the evolution of data acquisition system technology. The flexibility of FPGAs makes them ideal for custom data acquisition systems and embedded applications.