Fixing software bugs with JTAG technology
12 May 2017
From serial PROMs to SOCs and CPLDs to PMBus (power management) devices, the number of programmable parts on today’s hardware designs is burgeoning - and for production engineers, this presents significant problems.
In the days when there was only one, or maybe two parts to consider, when firmware was simple (and rarely changed) and volumes were high, then the obvious mechanism was to have your silicon supplier pre-program the parts for a nominal charge. Over the past decade, however, changes in both attitudes and designs has led to far wider adoption of ‘in-system’, ‘in-circuit’ or ‘on-board’ programming as the standard method of work.
It is a commonly accepted fact that software is never finished or bug free. So unless your design is of similar complexity to a pre-millennium domestic appliance, there is a good chance its firmware will need periodic bug-fix updates and might also be subject to functional enhancements. This demands a stream of new firmware revisions, if not for the lifetime of the product, then at least during its formative days.
Methods for in-system programming can vary from ICT (In-Circuit Tester) access (for example, to the pins of parallel NOR flash) from the standard ICT pins, dedicated programmers through ICT fixture pins, parallel I/O edge connector access, or JTAG and other serial access mechanisms.
Of these options, the last is emerging as the most versatile system and is especially suited to complex and/or bespoke programming setups. Its versatility is due, in part, to the fact that it supports both direct and indirect programming of parts.
Direct programming is the term used to describe parts that feature a JTAG (IEEE Std 1149.1) port, or similar serial interface, that support the configuration of internal registers or embedded memories with a private instruction set, or instructions that comply with the IEEE 1532 in-system configuration standard. In these type of parts, the programmability has been designed-in and generally offers a rapid method to configure the device. Examples of directly-programmable parts include CPLDs from Altera, Lattice Microsemi (Actel) and Xilinx (Figure 1), along with micros with embedded flash supplied by Analog Devices, Infineon, Microchip, NXP (Freescale), Renesas, Silicon Labs, ST, TI and others. Some device types, such as power management chips, even have specific bus types, such as PMBus, to directly program them.
Indirect programming on the other hand requires no special infrastructure within the device itself. Instead, target parts are accessed via other elements of the design. A classic example of the indirect method is the use of JTAG/boundary-scan compliant devices, such as microprocessors or FPGAs, to access standard flash memory (data, address and control lines) via the embedded boundary-scan (shift) register (see Figure 2). This method for programming flash in-system provides a reliable capability and works well for memories of up to 16Mbytes; however, depending on the boundary-scan device used for access, it can prove too slow for high volume production (shift register lengths are too long). To increase the throughput of programming using this method, several speed-enhancing options are available.
When an FPGA is used to access flash memory, most devices now offer a bridge from the JTAG infrastructure to the FPGA fabric. By pre-programming (via JTAG) the FPGA fabric to include a shorter equivalent boundary-scan shift register, the required number of shifts needed to reproduce a write cycle can be dramatically reduced.
For FPGA-based programming of a discrete device, a further option is to use a dedicated WSM (Write State Machine) IP block to write at full system speed to the flash. This could also be coupled to a high-speed serial bus interface such as Ethernet or an SD-card. The communications between the blocks can be orchestrated via JTAG (see Figure 3).
Similar to the method outlined above, the JTAG debug resources of a microprocessor can also be used to access (via an internal bus) a memory controller that will program the flash at high speed.
Available software tools
For all directly-programmable devices, the device developer normally supplies a proprietary tool that serves their part(s). However, it is unlikely that the tool will support any other manufacturers’ parts, and what’s more, may not be of sufficient quality (in terms of speed and build) to serve as a production programmer. Dedicated test and programming suppliers, such as JTAG Technologies, however, can offer rugged hardware, multi-vendor support, plus software tools and drivers to allow their programming solutions to be embedded in a wide range of production software platforms (from NI, Keysight, Geotest, Teradyne, Spea and others). JTAG ProVision not only plays standard programming file formats such as SVF, JAM, STAPL and ISC, it can also generate a wide range of board-specific indirect programming set-ups for flash devices (NOR and NAND), serial PROMs, PMBus devices and so on. At the last count, ProVision developer software included models for over 3000 flash device types.
Available hardware interfaces
The JT 37x7 ‘DataBlaster’ family from JTAG Technologies (Figure 4) offers the highest performance for both direct and indirect programming applications. The standard hardware configuration supports JTAG (IEEE Std 1149.1 interface), but upon request the unit can also be supplied with modules that communicate in SWD (single wire debug), BDM (background debug mode), Microchip PIC ICSP and PMBus, among others. As the JT 37x7 unit features four interface module slots, it can be used for simultaneous ‘gang programming’ of up to four targets, or programming of four different device or bus interface types. The actual execution of the programming applications can take place using compatible drivers for NI’s LabVIEW or TestStand, MS .NET, ATEasy or simply command line execution within batch files.
Board test comes as standard
Using a JTAG-based controller for your in-system device configuration means you also have board-level testing features available as standard. For over 25 years, test engineers have used JTAG/boundary-scan features on their boards to generate structural tests of device-to-device interconnections, memory block connection tests, and also functional-style tests on logic clusters and mixed signal devices, such as ADCs and DACs.
Contact Details and Archive...