Complex programmable logic devices, commonly known as CPLDs, have become a staple for modern digital electronic design. Although CPLDs have their limitations (they are primarily used for relatively small amounts of digital logic and low-power architectures), they are hard to beat their combination of low power consumption, on-the-fly design flexibility, and robust operation within a single component.

InHand engineers have used CPLDs for purposes ranging from very sophisticated (screen rotation, display timing, and video translation) to simple (GPIO manipulation and voltage level translation). This blog describes their use for resolving unforeseen issues and design enhancements.

One recent example involves a custom electronic device that InHand had designed, tested, and completed a low rate initial production (LRIP) manufacturing build. This rugged product successfully completed extensive testing by a third-party test lab: MIL-STD-461 for electromagnetic compliance; MIL-STD-810 for environmental conditions including temperature, shock, vibration, ingress protection, and more; FCC Part 15 for regulatory electromagnetic compliance; and 4G LTE cellular including PTCRB and cellular carrier requirements. At this point, volume production was about to commence on a very short timeline. Any change in the hardware would have significant impact on project schedule and cost, since the product was demonstrated via formal test to comply with requirements, and was authorized for production by our client.

However, late requirements brought in from the field and further testing at our client’s site uncovered two unforeseen issues. The first issue resulted from system vibration. The second issue arose when testing change-over of power sources. Between these two issues, the unit could not be fielded as it was designed and tested, leaving our client with the unpleasant choice of updating the hardware (and retesting), creating expensive custom cables, or modifying the ancillary equipment.

Fortunately, InHand had designed flexibility into the front end power-architecture that enabled a fourth choice. InHand had implemented a CPLD to host core logic in general and various aspects of the device power architecture. Given this, InHand determined it was theoretically possible to tackle both of these new issues with a CPLD firmware change.

By design, this product could be powered and unpowered in a variety of ways –in all cases, it had to provide continuous operation of the device without causing a reboot. The device could be connected to an external source (potentially noisy vehicle power), a battery, or both. The logic was designed to switch to the external source when present, and to allow any combination of connections or disconnections without disrupting device operation.

In the lab, all use cases worked as designed. In the field, however, the first issue discovered was that due to the method of applying power (plugging in a cable), there could be some rapid connections/disconnections as the cable was plugged in, causing power glitches that could cause the unit to reboot. This could easily be fixed in hardware by adding a filter to smooth the external power, but this was extremely undesirable since the electronics had already completed compliance testing. Instead, InHand added debounce logic in the CPLD, effectively filtering the power switching logic that delays powering the unit until the power source is stable.

The second issue involved a particular piece of auxiliary peripheral equipment that was sensitive to noise on the serial port when first powered up. This could have been addressed on the peripheral equipment, as the noise did not impact operation of the InHand designed electronic device. However because this peripheral equipment was already fielded, any change to it would have been costly, time-consuming, and highly inconvenient. Filtering a glitch  on a UART transmit line (controlled through the CPLD) addressed the problem via the InHand-provided device with no impact to other equipment.

None of these problems or requirement updates were anticipated at the project outset. With the use of a CPLD for some of the core logic functions within the device, InHand’s engineers were able to solve complex device initialization and power-sequencing logic without hardware changes and with minimal retesting. Volume production and fielding of this device continued on schedule and on-budget.

The utility of solving these issues through a CPLD update would be limited if the infrastructure and ability to update the CPLD firmware is complex or unwieldy. As a routine part of our core design structure, InHand typically implements the ability to perform CPLD firmware updates in the field through several different mechanisms, chosen based on specific product requirements. Options include providing an update file physically to the device (such as via a USB port), over a network (such as Ethernet), or over the air (OTA) via cellular communications or other wireless interface. These methods use signed image authentication for device security. Remote updates allow the latest features to be efficiently deployed at every stage of the product life cycle (prototype verification, manufacturing, in the field, and at a repair depot).

Whereas the ability to address these types of issues in firmware is extremely powerful, it is only a reality if the design supports the flexibility up front. Well thought out embedded device architecture, intelligent selection of the capabilities of the CPLD, careful consideration of the use cases, and deep thought into maintaining control of a variety of signals is the hallmark of a design that can withstand field-update and modifications with no or limited hardware changes.