Final Year Project Report

Final Year Project Report Project Title: Implementation of JTAG (IEEE 1149.1) Demo System combined with a set of test programs Student Name: Frank ...
Author: Jade Small
53 downloads 0 Views 2MB Size
Final Year Project Report Project Title:

Implementation of JTAG (IEEE 1149.1) Demo System combined with a set of test programs

Student Name:

Frank Leonard

Student ID:



Ciaran Mac Namee


Information Technology and Telecommunications

Academic Year:


Submitted in part requirement for final year project To University of Limerick April 2006

‘Implementation of JTAG (IEEE 1149.1) Demonstration System combined with a set of test programs’


Table of Contents








Chapter 1: INTRODUCTION AND AIMS 1.1 1.2 1.3


12- 18

Motivation and Aims for the project Introduction to Boundary Scan Introduction to USB

Chapter 2: INVESTIGATING BOUNDARY SCAN 2.1 2.2 2.3 2.4




History of Printed Circuit Board Testing Architecture of Boundary Scan The TAP controller Fixtureless Testing using Boundary Scan 2.4.1 What is needed for boundary-scan access? 2.4.2 What can be accomplished with boundary-scan? 2.4.3 Economic Benefits of Boundary-Scan.



Introduction Software IDE Technologies 3.1.1 JBuilder Enterprise Edition 3.1.2 MPLAB IDEv7.31 3.2 Choosing Software IDE Technologies 3.3 Hardware Technologies 3.3.1 Picdem FS USB Demonstration Board 3.3.2 PF2152 JTAG Technologies Experiment Board 3.4 Choosing Hardware Technologies Chapter 4: ANALYSIS AND DESIGN

30- 47


4.1 4.2


Introduction Requirements and Use Cases 4.2.1 System Requirements 4.2.2 Use Case Diagrams 4.3 Design Methodology 4.3.1 GUI 4.3.2 USB Interface 4.3.3 Hardware Chapter 5: IMPLEMENTATION AND DISCUSSION

56- 64


5.1 Introduction 5.2 GUI 5.3 USB Interface 5.4 C Code 5.5 C Functions 5.6 Hardware 5.7 Testing CONCLUSIONS

65- 66


67- 68


69- 93





This Final Year Project is presented in partial fulfilment of the requirements for a B.Sc in Information Technology and Telecommunications.

It is entirely my own work and has not been submitted to any other University or higher education institution, or for any other academic award in this University. Where use has been made of the work of other people it has been fully acknowledged and fully referenced.







I would like to sincerely thank my supervisor Ciaran Mac Namee for all his help, support and patience throughout this project. I would also like to thank all the lecturing staff of the University of Limerick for the past four years of guidance.

I would especially like to thank my parents and family for their love and encouragement. Thank you, finally, to all my friends for their backing and friendship over the years.





The aim of this project is to design, implement and test a demonstration system that can show how the IEEE 1149.1(JTAG) standard can be used to develop in-system PCB tests. The PF2152 experiment board from JTAG Technologies that uses switches and LED’s as its Input/Output is provided. This board allows a user to see how the JTAG interface works. The project involves programming to send JTAG commands from a GUI to the PF2152 experiment board via the USB port. The eventual aim of this project is to allow the board to be used for online experiments.

The project has fulfilled its primary objectives and a complete generic system has been created that is user friendly.

The project implements some of the latest technologies available for developing such an application while exercising standard design methodologies.


Chapter 1: Introduction & Background Theory



1.1 MOTIVATION AND AIMS FOR THE PROJECT The aim of this project is to develop an experimental demonstration system that can show how the IEEE 1149.1(JTAG) standard can be used to develop in-system PCB tests. The PF2152 demonstration board that uses switches and LED’s as its Input/Output is provided and this board allows a user to see how the JTAG interface works. This interface is used to read inputs and write outputs in the demo system. The project involves programming to send JTAG commands from the GUI to the experiment board via the USB port. The eventual aim of this project is to allow the board to be used for online experiments.

These days the electronics industry is getting more and more complicated. One single chip can contain millions of transistors and over 1000 I/O’s on a very small area. To verify that the behavior of the components is correct they need to be tested. Boundary Scan IEEE 1149.1 standard is a special method for test of digital components. A scan chain of scan cells is connected in a component. By controlling the scan chain it is possible to force the outputs to different values and then check if there are any faults.

As printed circuit boards (PCBs) become more complex the need to test them becomes more important. In the 1970’s and 1980’s the test system consisted of “bed of nails” and external test probes. The component technology of that era was dual in line and the PCBs had maximum two layers. It was easy to access all the soldering points. The nails hit 12

various points of the PCBs and measured the different values. This test systems isn’t able to access all the test points if the PCB have more than 2 layers, which is a big limitation, and SMT components is very hard to access because of the fine pitch lines. Some components, like BGA, PGA, flip-chip, isn’t possible to access at all and need a different method to be tested with. In the 1980’s Joint Test Action Group (JTAG) developed a Boundary Scan Standard that later was standardized as the IEEE Standard 1149.1. This standard describes how to implement scan chains into IC's. The IEEE 1149.1 also describes the Test Access Port (TAP) which includes several registers, some are standards and some are optional.

The trend is clear; board-level probing will become increasingly difficult and costly so that alternatives are needed. Boundary- Scan clearly makes a contribution to solving this problem and hence was a major motivation in this project.



IEEE Standard 1149.1-2001 also known as boundary scan is a testing standard. However, upon reading it, it may be thought of as a collection of design rules, and that these are applied at the Integrated Circuit (IC) level. Yet, the Standard is intended to have impact at several points in the life cycle of a product. These are: 

At the Integrated Circuit level. The Standard facilitates IC testing and has direct support for Built-In-Self-Test.

At the Printed Circuit Board level. The Standard facilitates Board Testing. It can be used for bench testing of prototype boards, for production testing and can be used to support emulation functions.

At the module or system level. The Standard can be used to support the testing of higher level assemblies from modules and boxes to full systems. Here the Standard may also cooperate with other standards.

Next, you will notice that the Standard has two major modes of operation. These modes are defined by setting up the 1149.1 portion of the ICs with specific instructions. These major modes are:


Non- Invasive. The Standard specifies a set of resources guaranteed to be independent of the rest of the logic within an IC. In Non- Invasive mode these resources are used to communicate asynchronously with the outside world to set up tests or read out results. These activities are invisible to the normal behaviour of the IC and may be conducted concurrently with them.

Pin- Permission. The Standard specifies instruction modes of operation that can usurp control of the input/output (I/O) pins of the IC, effectively disconnecting the ICs System Logic from the outside world. These modes allow the testing of the ICs System Logic or its isolation from testing activities taking place at its pins.

As technology evolved problems grew for previous In- Circuit testing. The In- Circuit approach depends on a bed-of-nails test fixture, such as the one shown in Figure 1-1, to gain access to the internal nodes of the DUT. In the 1970s and into the 1980s, IC packaging technology was dominated by dual-inline, through-hole-mounted packages. This meant that every board signal; was visible on the bottom of a board where they were soldered to though-hole package pins and the majority of these pins were spaced on tenth –inch(100-mil) centers. It was common to arrange In-Circuit fixture nails to target the IC pins themselves.

With the switch to Surface-Mount Technology (SMT) and much finer packaging geometries, new problems arose. First, there were no through- hole pin targets for InCircuit nails. Second, some board-level signals may never appear on the bottom side of the board if In-Circuit test access was not a design criterion. Third, for further packing density, ICs might be mounted on both sides of the board. This all led to access problems: some board nodes may be inaccessible to In- Circuit nails.


Figure 1-1: Cutaway drawing of a board resting on top of an In- Circuit, vacuumactuated test fixture: the “bed of nails”. The trend is clear; board-level probing will become increasingly difficult and costly so that alternatives are needed. Boundary- Scan clearly makes a contribution to solving this problem.

1.2 INTRODUCTION TO USB A USB system has an asymmetric design, consisting of a host controller and multiple daisy-chained devices. Additional USB hubs may be included in the chain, allowing branching into a tree structure, subject to a limit of 5 levels of branching per controller. Not more than 127 devices, including the bus devices, may be connected to a single host controller. Modern computers often have several host controllers, allowing a very large number of USB devices to be connected. USB cables do not need to be terminated.

USB is a likely solution any time you want to use a computer to communicate with a device outside of the computer. The interface is suitable for mass-produced, standard peripheral types as well as small-volume designs, including one-of-a-kind projects.


To be successful, an interface has to please two audiences: the users who want to use the peripherals and the developers who design the hardware and write the code that communicates with the device. USB has features to please both.

From the user’s perspective, the benefits of USB are ease of use, fast and reliable data transfers, flexibility, low-cost, and power conservation.

Ease of use was a major design goal for USB, and the result is an interface that’s a pleasure to use for many reasons. USB supports three bus speeds: high speed at 480 megabits/sec., full speed at 12 megabits/sec., and low speed at 1.5 megabits/sec. The USB host controllers in recent PCs support all three speeds.

The reliability of USB is due to both the hardware and the protocols for data transfer. The hardware specifications for USB drivers, receivers, and cables ensure a quiet interface that eliminates most noise that could cause data errors. The USB protocol enables the detecting of errors in received data and notifying the sender so it can retransmit. The detecting, notifying, and retransmitting are done in hardware and don’t require any programming or user intervention.

Even though USB is more complex than earlier interfaces, the components and interfaces are inexpensive. A device with a USB interface is likely to cost the same or less than an equivalent device with an older interface or a more recent interface such as IEEE- 1394.

Power saving circuits and code can automatically power down USB peripherals when not in use yet keep them ready to respond when needed. The reduced power consumption saves money, is environmentally friendly, and for battery powered devices, allows a longer time between recharges.

Many of the user advantages described above also make things easier for developers. For example, USB’s defined cable standards and automatic error checking mean that developers don’t have to worry about specifying cable characteristics or providing error checking in software.

USB has other advantages that benefit developers. The developers include the hardware 16

Designers who select components and design the circuits in devices, the programmers who write the software embedded in the devices, and the programmers who write the PC software that communicates with the devices. However, there is a lot of work involved for developers in designing and coding a USB interface.

The benefits to developers result from the flexibility built into the USB protocol, the support in the controller chips and operating system, and the support available from the USB implementer’s forum.

USB’s four transfer types and three speeds make the interface feasible for many types of peripherals. These are transfer types suited for exchanging large and small blocks of data, with and without time constraints. For data that can’t tolerate delays, USB can guarantee bandwidth or a maximum time between transfers. These abilities are especially welcome under Windows, where accessing peripherals in real time is often a challenge. Although the operating system, device drivers, and application software can introduce unavoidable delays, USB makes it as easy as possible to achieve transfers that are close to real time.

Windows 98 was the first Windows operating system with reliable support for USB, and the editions that have followed, including Windows 2000, Windows Me, Windows XP, and Windows server 2003, support USB as well. A claim of operating system support for USB can mean many things. At the most basic level, an operating system that supports USB must do three things: 

Detect when devices are attached to and removed from the system.

Communicate with newly attached devices to find out how to exchange data with them.

Provide a mechanism that enables software drivers to communicate with the computers USB hardware and the application that want to access the USB peripherals.

On the peripheral side, each USB device’s hardware must include a controller chip that manages the details of USB communications. Some controllers are complete microcontrollers that include a CPU, program and data memory, and a USB interface. Other controllers must interface to an external CPU that communicates with the USB controller as needed.


With, some interfaces, the user is on their own when it comes to getting a design up and running. With USB, there is assistance via the USB Implementers Forum, Inc. and its website [1]

USB does some have disadvantages. You have to see if these apply to your installations. 1. It is relatively new technology and not supported on older operating systems including Windows NT or Windows 95. To use this technology in Windows environment, you need minimum Windows 98, 98 SE (which fixes some bugs), Windows 2000. 2. It is a real time device, which means that if a plug in card (such as Xircom Ethernet PCMCIA card) holds the bus longer than it should there could be data loss on USB device.


Chapter 2: Investigating Boundary Scan





Functional testing is the original method of testing electronics. In the early days of the electronic industry, many systems were simply assembled and the power was switched on. By checking the functionality of the system, the “test” was performed.

Today, some companies still have to work in this way. However, the growing complexity of modern systems has made functional test preparation a lengthy job, while the fault coverage of such test programs may remain unknown. Moreover, diagnosing faults found in functional testing can be very difficult, often requiring highly skilled technicians in manufacturing. For this reason, testing is often performed at the printed circuit board (PCB) level prior to system testing. The PCB test might still be performed in a functional way, but by sub-dividing the problem, test preparation and diagnostics became more manageable. However, the rapidly increasing complexity of Integrated Circuits (IC) caused the same type of problems with PCB functional test as encountered at systemlevel; namely long test preparation times, uncertain fault-coverage, and poor diagnostics.

The next test method to be widely adopted was in-circuit testing (ICT). By providing direct electrical access to the components on a PCB via an electromechanical” bed of nails fixture, it was possible to test for manufacturing faults. This technology was well suited for dual-in-line packages (DIP) and plated-through-hole PCB technology. But along with newer fine-line PCBs and more complex array-style IC-packages, such as


BGA etc., with higher pin-counts and smaller pitches, test access has become severely limited. Fixturing technology could not keep up with the ever-decreasing dimensions of pins and pitches and the higher pin-counts of packages.

Fortunately, the industry anticipated these problems, and through a cooperative effort, the boundary-scan- method was developed and adopted as the IEEE Standard 1149.1 Test Access Port (TAP) and Boundary- Scan Architecture. The objectives of this powerful standard was to overcome many of the drawbacks of the other test technologies.[2]

The process of developing this standard began in 1985, when the Joint European Test Action Group (JETAG) was formed in Europe. During 1986, this group expanded to include members from both Europe and North America and, as a result, was renamed the Joint Test Action Group (JTAG). Between 1986 and 1988, the JTAG Technical Subcommittee developed and published a series of proposals for a standardized form of boundary scan. In 1988, the last of these proposals—JTAG Version 2.0—was offered to the IEEE Testability Bus Standards Committee (P1149) for inclusion in the standard then under development. The Testability Bus Standards Committee accepted this approach. It decided that the JTAG proposal should become the basis of a standard within the Testability Bus family, with the result that the P1149.1 project was initiated. Following these decisions, the JTAG Technical Subcommittee became the core of the IEEE Working Group that developed this standard.[3]



The basic architecture of 1149.1 Boundary scan is incorporated at the integrated circuit level. See the illustration in Figure 2-1. First, four new package pins are dedicated to Boundary- Scan. These pins form the Test Access Port (TAP) and must be dedicated to Boundary- Scan; they must not be shared with any other function. These pins are used with a simple protocol to communicate with on-chip Boundary-Scan logic.

The protocol is driven by two of the pins. These two input pins are a Test Clock (TCK) and a Test Mode Select (TMS). The remaining two pins are for serially shifting data into and out of the IC, labelled Test Data In (TDI) and Test Data Out (TDO). The Standard 21

requires that TMS, TDI and TRST* float high if they are unconnected (intentionally or due to a fault). This requirement enhances system reliability since these values on these pins permit fail-safe operation. Second, on the IC die itself, a simple finite state machine called the TAP controller. It recognises the communication protocol and generates internal control signals used by the remainder of the Boundary- Scan logic. The TAP controller is driven by TCK and TMS only; no other signals affect the TAP controller.

Third, on the die again, is a Boundary-Scan Instruction Register and decode logic. This register is controlled be the TAP and can be placed between TDI and TDO for loading and unloading serially shifted instruction data. The instruction register is used to set the mode of operation for one or more data registers. Several, instruction modes are mandated by the Standard. Others are described, but are optional. Rules are also that allow the addition of user-defined instructions and modes.

Last, also on the die, is a collection of Boundary-Scan data registers. Two are always required to be present on an 1149.1 component: the Bypass register and the Boundary register. Several others are described by the Standard such as device Identification Register, but are optional. Finally, rules are given for adding user-defined data registers.


System Outputs

System Inputs

Boundary Register Cell

Internal Core Logic



Bypass Instruction Register ID Register


TAP Controller

(Controls Signals)

Figure 2-1: General, simplified architecture of an 1149.1 compliant IC



The TAP controller is a finite state machine with a state diagram containing sixteen states. A transition between states only occurs on a rising edge of the Test Clock (TCK) or asynchronously with the assertion of Test Reset (TRST*) if it exists. An assertion of TRST* will always send the machine to the reset state. A synchronizing sequence for the state machine also exists: five cycles or TCK with TMS held high will set the machine to the reset state, regardless of its current position in the diagram. The state transition diagram is shown in Figure 2-2. It is the fundamental “roadmap” that all 1149.1 applications must follow. Each state contains a label. Each arc between states is labelled with a 0 or 1 indicating the logic value of TMS that must be set up before the rising edge of TCK to cause the transition. Falling edges of TCK do not cause state transitions, but


cause other actions within the architecture. The asynchronous transitions due to TRST* are not shown, but all lead to Test Logic Reset state.

Figure 2-2: State transition diagram of the sixteen state TAP controller Looking at Figure 2-2 you will notice that there are two vertical columns of seven states each and that they are identical except for the labels they carry. Furthermore, notice that the labels are quite similar. Indeed, the left vertical column is the data column and the right vertical column is the instruction column. These two columns reference data registers (DR) or the Instruction Register (IR) respectively. They behave in an otherwise identical fashion that greatly simplifies understanding them. The purpose of each some of the main states follows.[4]

Test-Logic-Reset The test logic is disabled so that normal operation of the on-chip system logic (i.e., in response to stimuli received through the system pins only) can continue unhindered. This is achieved by initializing the instruction register to contain the IDCODE instruction or, if the optional device identification register is not provided, the BYPASS instruction (see 7.2). No matter what the original state of the controller, it will enter Test- Logic-Reset when TMS is held high for at least five rising edges of TCK. The controller remains in


this state while TMS is high. If the controller should leave the Test-Logic-Reset controller state as a result of an erroneous low signal on the TMS line at the time of a rising edge on TCK (for example, a glitch due to external interference), it will return to the Test-LogicReset state after three rising edges of TCK with the TMS line at the intended high logic level. The operation of the test logic is such that no disturbance is caused to on-chip system logic operation as the result of such an error. On leaving the Test-Logic-Reset controller state, the controller moves into the Run-Test/Idle controller state, where no action will occur because the current instruction has been set to select operation of the device identification or bypass register. The test logic is also inactive in the Select-DRScan and Select-IR-Scan controller states. Note that the TAP controller will also be forced to the Test-Logic-Reset controller state by applying a low logic level at TRST*, if such is provided, or at power-up.

Run-Test/Idle A controller state between scan operations. Once entered, the controller will remain in the Run-Test/Idle state as long as TMS is held low. When TMS is high and a rising edge is applied at TCK, the controller moves to the Select-DR-Scan state. In the Run-Test/Idle controller state, activity in selected test logic occurs only when certain instructions are present. For example, the RUNBIST instruction causes a self-test of the on-chip system logic to execute in this state. Self-tests selected by instructions other than RUNBIST also may be designed to execute while the controller is in this state. For instructions that do not cause functions to execute in the Run-Test/Idle controller state, all test data registers selected by the current instruction shall retain their previous state (i.e., Idle). The instruction does not change while the TAP controller is in this state.

Select-DR-Scan This is a temporary controller state in which all test data registers selected by the current instruction retain their previous state. If TMS is held low and a rising edge is applied to TCK when the controller is in this state, the controller moves into the Capture-DR state and a scan sequence for the selected test data register is initiated. If TMS is held high and a rising edge is applied to TCK, the controller moves on to the Select-IR-Scan state. The instruction does not change while the TAP controller is in this state.

Select-IR-Scan 25

This is a temporary controller state in which all test data registers selected by the current instruction retain their previous state. If TMS is held low and a rising edge is applied to TCK when the controller is in this state, then the controller moves into the Capture-IR state and a scan sequence for the instruction register is initiated. If TMS is held high and a rising edge is applied to TCK, the controller returns to the Test-Logic-Reset state. The instruction does not change while the TAP controller is in this state.

Capture-DR In this controller state data may be parallel-loaded into test data registers selected by the current instruction on the rising edge of TCK. If a test data register selected by the current instruction does not have a parallel input, or if capturing is not required for the selected test, the register retains its previous state unchanged. The instruction does not change while the TAP controller is in this state. When the TAP controller is in this state and a rising edge is applied to TCK, the controller enters either the Exit1-DR state if TMS is held at 1 or the Shift-DR state if TMS is held at 0.

Shift-DR In this controller state, the test data register connected between TDI and TDO as a result of the current instruction shifts data one stage toward its serial output on each rising edge of TCK. Test data registers that are selected by the current instruction but are not placed in the serial path retain their previous state unchanged. The instruction does not change while the TAP controller is in this state. When the TAP controller is in this state and a rising edge is applied to TCK, the controller either enters the Exit1-DR state if TMS is held at 1 or remains in the Shift-DR state if TMS is held at 0.


Fixtureless Testing using Boundary Scan


What is needed for boundary-scan access?

The first requirement is to use boundary-scan compatible devices in your design. Because many ICs from a large number of silicon vendors have boundary-scan already built in, this requirement is often easily met.


Moreover, to achieve good test coverage, it is not necessary to have all devices equipped with boundary-scan. For example, there may be clusters consisting of non- boundary scan parts that will be testable despite lack of direct boundary scan access. In fact, practical examples exist in which an entire PCB is controlled, observed, and thoroughly tested (including memories) from just one or a small number of boundary-scan devices.

Accessing the boundary- scan devices in your design is a simple matter. The boundaryscan components are interconnected in a chain (or multiple chains) on your board. This is done be sequentially connecting the boundary- scan data output pin (TDO) on one device to the boundary-scan data input pin (TDI) of the next device, and so on. To control this “test infrastructure” which includes the shifting operations etc., each boundary-scan device is connected to the test clock (TCK) and the test mode select (TMS) signal.


What can be accomplished with boundary-scan?

Boundary- scan was invented to overcome the manufacturing test access problems anticipated with in circuit testing of surface mount technology designs. In fact, several different types of tests can be conducted via boundary-scan.

Moreover, manufacturing testing is not the only application fro the serial bus and the Test Access Port (TAP). Due to the simple means of access for test purposes, the ease of test preparation and the low cost of the tools, boundary scan is often successfully applied to testing prototypes for manufacturing faults. Without boundary-scan capability, prototype testing may take several days or even weeks, consuming the scarce time of the designer. Furthermore, by using boundary-scan, the prototype test to screen out structural faults can be performed by production personnel, since no special knowledge is needed of the logic functions of the PCB.

In addition to board testing, the boundary- scan infrastructure can be used to program flash memory devices and PLDs after board assembly. Successful flash programming requires access to the address, data and control pins of the flash memory device via boundary-scan cells, a requirement which is usually easily met.

2.4.3 Economic Benefits of Boundary-Scan. 27

The advantages of boundary-scan that have been discussed earlier can be translated into solid commercial benefits by shortening critical manufacturing processes and hence the time-to-market, by saving in capital investment, and by reducing the cost of ownership.

The significant benefit of reducing time-to-market on profitability has been documented in various studies. One such study reveals that, on average, after-tax-profit is adversely impacted by 33% when a product is shipped six months late, as compared to only a 3.5% reduction of profit, when the product development expenses are overspent by 50%. Also, the faster a product is introduced into a competitive market, the longer will be the potential lifetime and hence the greater its return on investment.

The introduction of boundary-scan testing further reduces the investments for testing, particularly in the manufacturing phase of the product lifecycle. This reduction has three causes: 

A boundary- scan test system is much less expensive than a traditional ICT tester, roughly an order of magnitude lower.

Costly fixtures are either eliminated or simplified, resulting in saving that multiply with each board type to be tested.

Fewer testers may be needed due to shorter fault diagnosis times, which in turn allow the factories throughput per tester to be increased.

Establishing boundary-scan as a corporate design rule to support DFT implies that the designers will consider production issues before the design begins. Innovative solutions are fostered before legacy implementations can block them. These phenomena contribute to the improvement of quality, reliability, and testability of the electronic products and systems.

An inherent characteristic of boundary-scan testing is the compatibility between the product to be tested and the test equipment. This results from boundary-scan being embedded in the logic of the functional design. This is never a mismatch or divergence of technologies as can happen with bed of nails systems, in which a conflict may arise between fixture engineering and the shrinking device sizes and novel packaging technologies. These conflicts can clearly influence the quality of testing and consequently the product quality. 28

Because of the short test preparation lead times, boundary- scan tests are ready prior to manufacture start up. The benefits are the avoidance of ad-hoc test methods and immediate use of the standard test procedures. In contrast, traditional functional or incircuit test programs are often either not available in time or do not offer high fault coverage at the outset of manufacturing. The impact of these shortcomings on customer’s expectations and your brand name and service costs can be disastrous for the long term growth for your company.

The very high fault coverage of the boundary-scan test and the high degree of diagnostic capabilities lowers the rate of faults that are undiscovered during the manufacturing phase, resulting in a lower cost of ownership through improved quality and reliability.


Chapter 3: Enabling Tools & Technologies





There are many technologies available today for the development of this type of application, each with their own advantages and disadvantages. Time spent choosing the right technology initially saves time in the long run, as some technologies are more suited to certain tasks than others. This section describes the main technologies used for developing this application and the factors taken into account when choosing which of these technologies to use.



3.2.1 JBuilder Enterprise Edition

JBuilder is an award-winning integrated development environment (IDE) for the Java programming language. JBuilder includes a comprehensive collection of tools, designers, and wizards to help you design, develop, test, deploy, and manage your Java applications throughout their lifecycle. JBuilder also includes many ready-made


components and templates to further increase consistency and productivity. JBuilder uses one window to perform most of the development functions: editing, visual designing, navigating, browsing, compiling, debugging, and other operations. This window is JBuilder’s workspace, and it contains several panes for performing these development functions. You can undock the panes that comprise the JBuilder JBuilder workspace. The tabbed panes that are available in the content pane depend on what kind of file you have selected in the project pane.

The JBuilder menu bar is at the top of the JBuilder workspace, below the title bar. The availability of some menus and menu commands depends upon the personalities selected in the project properties.

The main toolbar is displayed at the top of the IDE under the menu bar. It is composed of smaller toolbars grouped by functionality: File, Editing, Search, Build, Run/Debug, Navigate, Help, and Workspaces. You can modify the toolbar display by checking or unchecking selections on the View Toolbars menu. You also can view the toolbar button, name and a brief description of the button by moving your cursor over the button. The button name appears below the button, and a brief description of the button appears in the main status bar.

The content pane displays all opened files as a set of tabs. To open a file in the content pane, either double-click it in the project pane or select it in the project pane and press Enter. The name of each open file is displayed on its tab at the top of the file in the content pane. When you click on a file tab, that file becomes the current or active file and can be edited directly. To customize the content pane tabs, choose Tools|Preferences and change the settings on the Content pane page. You can also customize the configuration of the panes in JBuilder’s IDE. You can open files from different projects at the same time, but only one project at a time appears in the project pane. To switch between projects, select the desired project from the project pane toolbar’s drop-down list or from the Window menu. When you switch to another project, that project appears in the project pane and its open files become accessible in the content pane. You can split the source view of a file into two or more vertical or horizontal panes. This setting applies to an individual file, not to all the opened files in the content pane. You can have a different configuration for every opened file. To split the view into panes, click and drag a file’s tab when the Source tab is selected. 32

The project pane is, by default, in the top left of the JBuilder workspace. It is a movable pane. The project pane shows the current open project and all the nodes (files, packages, and descendants) it contains. It also displays a project group node, when the open project is a member of a project group. When your workspace is configurable, the project pane can be docked (attached to the workspace), undocked (free floating), or iconified (reduced to an icon on the left border of the workspace).

The structure pane is located, by default, in the lower left of JBuilder’s IDE. It is a movable pane. When a file type with appropriate content is open in a viewer that can provide structural information, this pane displays a structural analysis of the contents of the file. You can think of the structure pane as a table of contents for the file. You can also use the structure pane to navigate the file. For example, if you have a .java file open in the Source view, you see classes, variables, methods, and interfaces in the structure pane. You can then click any of these elements in the structure pane and the editor moves to and highlights that element in the source code. This gives you a much faster way to browse and find the elements of a .java file than scrolling through it or searching for a word. You can also search the structure pane for a particular element by moving focus to the tree in the structure pane and beginning to type. Right click in the structure pane to see the context menu. With certain types of files open in certain views, you can, 

Change the display order of the structure elements by choosing Properties from the context menu

Filter what appears in the structure pane by using the buttons on the structure pane’s toolbar

The tabbed message pane appears in the lower part of JBuilder’s IDE, below the Structure and content panes. If your code has errors when you compile, error messages are listed in the message pane. To go to the line of code with the error, click the error message. As you run an application, the message pane displays a tab with the name of the active process. For more information, see the status bar. When debugging, the debugger user interface and debugging process are in the message pane. Output from the selected server is also displayed in the message pane. Additionally, refactoring details are displayed in the message pane.


Menu Bar

Structure Panel

Project Pane


Content Pane

Status Bars

Application Applet

Message Pane

Figure 3-1: JBuilder IDE

Menu bar The menu bar includes several menus of commands for designing, developing, testing, deploying, and managing your Java applications. The menu bar includes the following menus: File, Edit, Search, Refactor, View, Project, Run, Team, Enterprise, Tools, Window, and Help. The commands available in each menu vary by JBuilder edition.

Main toolbar The main toolbar is displayed at the top of the JBuilder workspace under the menu bar. It is composed of smaller toolbars grouped by functionality: File, Edit, Search, Build, Run/Debug, Navigate, Help, and Workspaces. The buttons available for each of the smaller toolbars varies by JBuilder edition.

Content pane This is the largest pane, hosting the main views of the open files. Many files can be open in the content pane, but only one file at a time can be active. You can change the view for the active file by clicking the file tabs at the bottom of the content pane. Possible views


include the Source, Design, Bean, UML, Doc, and History views, depending on the type of file that is active. The availability of views and their features vary by JBuilder edition.

Project pane Displays the contents of the active project and provides right-click access to project-wide commands. It provides a file browser, opened from the Files tab, and a class browser, opened from the Classes tab. The tabs can be turned on and off from the View menu (View|Panes). The Classes tab is off by default.

Structure pane Displays the structure of the file currently active in the content pane. The structure pane hosts different views, so what appears in the structure pane is pertinent to the view tab selected in the content pane. Structure pane filter settings also affect the structure pane view.

Message pane Displays the output of various processes, such as compiler messages search results, debugger UI, refactoring, Javadoc, unit testing, viewing todos, version control commands, and WS-I testing tools functions for web services. It can also host modeless components. For example, when you start a debugging session, the debugger appears in the message pane. The CaliberRM plug-in (JBuilder Enterprise) is also displayed here.

Status bars JBuilder’s status bars display messages and features relevant to the frame and view they pertain to, and to what’s happening in the active file. [5]


3.2.2 MPLAB IDEv7.31 MPLAB IDE is a software program that runs on a PC to develop applications for Microchip Microcontrollers. It is called an Integrated Development Environment, or IDE, because it provides a single integrated “environment” to develop code for embedded microcontrollers.

An embedded system is typically a design making use of the power of a small microcontroller. These microcontrollers combine a microprocessor unit (like the CPU in a desktop PC) with some additional circuits called “peripherals”, plus some additional circuits on the same chip to make a small control module requiring few other external devices. This single device can then be embedded into other electronic and mechanical devices for low-cost digital control.

The main difference between an embedded controller and a PC is that the embedded controller is dedicated to one specific task or set of tasks. A PC is designed to run many different types of programs and to connect to many different external devices. An embedded controller has a single program and, as a result, can be made cheaply to include just enough computing power and hardware to perform that dedicated task. A PC has a relatively expensive generalized central processing unit (CPU) at its heart with many other external devices (memory, disk drives, video controllers, network interface circuits, etc.). An embedded system has a low-cost microcontroller unit (MCU) for its intelligence, with many peripheral circuits on the same chip, and with relatively few external devices. Often, an embedded system is an invisible part, or sub-module of another product, such as a cordless drill, refrigerator or garage door opener. The controller in these products does a tiny portion of the function of the whole device. The controller adds low-cost intelligence to some of the critical sub-systems in these devices.

An example of an embedded system is a smoke detector. Its function is to evaluate signals from a sensor and sound an alarm if the signals indicate the presence of smoke. A

small program in the smoke detector either runs in an infinite loop, sampling the signal from the smoke sensor, or lies dormant in a low-power “sleep” mode, being awakened by a signal from the sensor. The program then sounds the alarm. The program would possibly have a few other functions, such as a user test function, and a low battery alert. While a PC with a sensor and audio output could be programmed to do the same function, it would not be a cost-effective solution (nor would it run on a nine-volt battery, unattended for years!) Embedded designs use inexpensive microcontrollers to put intelligence into the everyday things in our environment, such as smoke detectors, cameras, cell phones, appliances, automobiles, smart cards and security systems.

The process for writing an application is often described as a development cycle - as it is rare that all the steps from design to implementation can be done flawlessly the first time. More often code is written, tested and then modified in order to produce an application that performs correctly. The Integrated Development Environment allows the embedded systems design engineer to progress through this cycle without the distraction of switching among an array of tools. By using MPLAB IDE, all the functions are integrated, allowing the engineer to concentrate on completing the application without the interruption of separate tools and different modes of operation.

Figure 3-2: The Design Cycle The IDE is a “wrapper” that coordinates all the tools from a single graphical user interface – usually automatically. For instance, once code is written, it can be converted to executable instructions and downloaded into a microcontroller to see how it works. In


this process multiple tools are needed: an editor to write the code, a project manager to organize files and settings, a compiler or assembler to convert the source code to machine code and some sort of hardware or software that either connects to a target microcontroller or simulates the operation of a microcontroller.

Figure 3-3: MPLAB IDE Converts Source Code into Machine Instructions The MPLAB IDE desktop is a resizable window that operates independent of the rest of the menu items. The desktop consists of a menu bar, tool bars, a status bar and any open windows and/or dialogs.[6]

Figure 3-4: MPLAB IDE



CHOOSING SOFTWARE IDE TECHNOLOGIES The decision on what IDE and programming language to use was based on a

number of factors including:

Availability of Software IDE?

Is it easy to learn?

Does it complete required tasks?

Taking these factors into account JBuilder Enterprise Edition and MPLAB IDEv7.31 were chosen as the software IDE technologies.

At the beginning of the project JBuilder Enterprise Edition was available to the author and also available on the PCs in the University. This availability made it a good choice as an IDE. Use of JBuilder Enterprise Edition is being taught in ET4718 Java Programming and Introduction to Software Engineering which led to a good learning environment. Through research it was found that JBuilder Enterprise Edition would be more than capable of completing the required tasks. These factors led to a decision to use it as an IDE.

MPLAB IDEv7.31 is available as a free download from the microchip web site thus instant availability. It is a challenging piece of software to learn but there is a good user guide and also an online users forum should one encounter any major problems. Through research it was found that MPLAB IDEv7.31 would indeed be capable of completing the required task.

Time spent choosing the right technology at this stage saves time in the long run.




3.4.1 PICDEM FS USB Demonstration Board The PICDEM FS USB Demonstration Kit is designed as an easy-to-use evaluation platform for Microchip’s Full Speed USB solution. The devices in Microchip’s new family of full-speed USB microcontrollers fully support USB 2.0 and serial communications of up to 12 Mbit/s.The Demonstration Kit provides all of the hardware and software needed to demonstrate and develop a complete USB communication solution. The microcontroller for the PICDEM FS USB board is the PIC18F4550. This device implements power-saving nanoWatt Technology, enhanced Flash program memory and features USB modules with the following: 

USB 2.0 compliance

Full-speed (12Mbit/s) and low-speed (1.5Mbit/s) operation

Support of control, interrupt, bulk and isochronous transfers

Support of up to 32 endpoints

1 Kbyte of dual-access RAM for USB

On-chip features for a true single-chip USB implementation, including

- USB transceiver - USB voltage regulator - USB pull-up resistors 

Interface for off-chip USB transceiver

The included reference designs and examples use the Microchip USB Firmware Framework. This provides the services for handling lower-level USB protocol management, control transfer, USB interrupt handling, hardware register control and management. Reference designs included with the demonstration kit cover Human


Interface Devices (HID), the Communication Device Class (CDC) and the Microchip General Purpose USB device class. The software consists of the Microchip General Purpose USB Windows driver, mchpusb.sys, which allows a PC application to communicate directly to the device’s endpoints. A set of user-friendly programming interfaces, the MPUSBAPI Library, is also provided to allow easy application development. The board comes pre-programmed with a default demo application and is ready for evaluation right out of the box. New programs can be downloaded to the PIC18F4550 microcontroller using a pre-programmed bootloader via the USB interface. A PC-based application, the PICDEM FS USB Demo Tool, facilitates the bootloading process and serves as the host application in the default demonstration.

The PICDEM FS USB demonstration board provides two simple advantages:

A READY-TO-USE DEMONSTRATION: As delivered, the board is ready for full-speed USB operation; all that is required is the proper driver (included) and the Demo Tool application. Users can also re-program the board with different applications, included on the Starter Kit CD, to evaluate other USB solutions that can be tailored to their needs.

AN EXPANDABLE PLATFORM: Users can also expand the hardware capabilities of the board through its expansion headers, and even interface it with available PICtail™ demonstration and evaluation daughter boards.

The overall layout of the board is shown in Figure 3-5, with a list of some of the main features following.


Figure 3-5: The PICDEM FS USB Board (Top Assembly view) 1. Microcontroller: The 44-pin, TQFP PIC18F4550 microcontroller (U2) is the heart of the demonstration board, and provides all USB functionality on one chip. Refer to the device data sheet (DS39632) for a complete discussion of the microcontroller and its feature set.

3. Oscillator: The demonstration board uses a 20 MHz crystal oscillator (Y1) as the primary clock service. The PIC18F4550 uses this oscillator to generate the necessary clock signals for both the USB serial interface engine (SIE) and the core processor.

5. Expansion and PICtail Headers: The pads at J6 and J7 are provided for users to install header and directly access the microcontroller’s I/O port signals. In addition, the 14 even numbered pins of J6 (those on the right side as viewed from the top) serve as the interface. This allows the PICDEM FS USB board to be used as a test platform and USB communications interface for the PF 2152 JTAG Technologies experiment board.


6. Configuration Jumpers: A total of 13 unpopulated jumper positions are provided across the board; these allow users to modify the board by configuring its hardware to suit their needs. By default, all jumpers are bridged and all features are enabled.

9. Power LEDs (Green): These light to show that power is being supplied to the board, and to indicate how the board is being powered. LED D7 indicates that the board is being powered from the bus, while D8 indicates the board is being powered from a separate power supply.

10. Reset Push Button: This switch (S1) is tied to the MCLR pin of the PIC18F4550 controller; pressing it causes a hard device reset.

11. Power Connector: Power (9 VDC) can be supplied to the board from an external power adapter through a mini barrel jack. Using an external supply is optional, as all examples provided with the demonstration board can use power from the USB cable.

12. USB Connector: This is a standard USB series “B” receptacle. The USB port is the primary channel for controlling and communicating with the demonstration board.

14. Status LED Bank: A bank of four green LEDs is used to show the operational status of the board. Two LEDs (D1 and D2) are used by the application firmware to indicate the status of the USB connection. The other LEDs (D3 and D4) can be defined by the user; they are directly controllable through the Demo Tool software.

15. User-defined Push Buttons: These two switches (S2 and S3) are provided to simulate digital control inputs. Pressing either button causes its port to read as ‘0’ . 16. RS-232 (DB9F) Port: A standard D-shell connector, along with a standard level shifter (U1), provides an RS-232 serial connection to the demonstration board. This could be used as an alternative to USB.


3.4.2 PF 2152 Experiment Board, JTAG Technologies The PF 2152 experiment board is used to enable the user to confirm that they have correctly installed the hardware and software supplied with their JTAG technologies package.

This is achieved by connecting the supplied PF 2152 experiment board to the JTAG controller and then performing an Infrastructure test to confirm the integrity of the boundary-scan chain. Without an intact Bscan chain it is not possible to complete the various types of Bscan testing or to transfer programming instructions to Flash devices or PLDs.

If the user has developed a test development package they will have the opportunity to perform some of the various types of boundary-scan tests. If they have a programming development package they will be able to confirm the principle of using a boundary scan chain to transfer control instructions to an electronic device, by making the LEDs on the PF 2152 experiment board light up in sequence.

Figure 3-6: PF 2152 Block diagram 1 In the normal functional mode, the LEDs at the outputs of D2 reflect the settings of the switches at the inputs of D1.


Jumpers The picture below indicates the factory default positions of the jumpers on the PF 2152.

Figure 3-7: Default position of Jumpers The group of jumpers located immediately below the TAP connectors are used to configure the PCB to have a single Boundary- scan chain or two separate chains. All jumpers must be in the lower position to have a single Boundary Scan chain as shown above. Infrastructure faults can be introduced by removing one or more of these configuration jumpers. The block of jumpers located between the two devices D1 and D2 allow for introduction of one or more interconnect faults by removing one or more of the jumpers.[7]

The PF 2152 experiment board is included in most JTAG technologies packages to enable the user to confirm that their hardware and software installation is working correctly. The PF 2152 is simple to use and produces predicable results.


Figure 3-8: PF 2152 board used to confirm correct installation of Hardware and Software



The decision on what Hardware technology to use was based on a number of factors including:

Availability of Hardware?

Is it easy to learn?

Does it complete required tasks?


Taking these factors into account the PICDEM FS USB Demonstration Board and the PF 2152 JTAG Technologies Experiment Board were chosen as the hardware technologies to be used in this project.

The PICDEM FS USB Demonstration Board was readily available and was purchased on the Farnell website for $37.47. The package contained a CD with a good user guide and also some good examples code and APIs which made the learning experience easier. As shown in section 3.4.1 the PICDEM FS USB Demonstration Board is capable of completing the tasks required of it.

The PF 2152 JTAG Technologies Experiment Board was available through the author’s supervisor in the University. All that accompanied this board was a schematic of the board. This created a challenging learning environment. As outlined in section 3.4.2 the PF 2152 JTAG Technologies Experiment Board was an ideal choice for the tasks required of it.


Chapter 4: Analysis & Design





This chapter covers the Analysis and Design of the GUI interface and the USB interface. It details the design methodologies used and includes UML diagrams illustrating the systems analysis completed.


The aim of this project is to develop an experimental demonstration system that can show how the IEEE 1149.1(JTAG) standard can be used to develop in-system PCB tests. A demonstration board that uses switches and LED’s as it’s Input/Output is provided and this board allows a user to see how the JTAG interface works. The project involves programming to send JTAG commands from the GUI to the experiment board via the USB port. Each element of the project must be objectively analysed and designed in a structured process that will be described in this chapter.

It is important to exercise proven design methodologies rather than rushing into the implementation of an application that contains a degree of complexity. With this in mind the design methodology used for this project is an iterative process loosely based on the Rational Unified Process (RUP). The RUP contains nine steps as illustrated below in Fig 4.1. In the case of a large team certain team members may specialise in a certain aspect of this process, such as test. When this is the case there may be a lot of work done in an iteration of the process. As this project is on a smaller scale, the work completed during each iteration is quite small, so a many iterations of this process are required to complete the entire application.

Fig 4.1 Rational Unified Process Methodology (Based on diagram by Conallen 2000, pp. 93)


In effect each part of this application is completed by iterating through the RUP cycle a number of times, with the end result being a system comprising of many individually developed and tested parts.

Iteration may be quite short if the requirements are straightforward and longer for the more complicated requirements. Thus a few iterations of this cycle may be completed in a couple of hours in the design of this application, unlike the two weeks or so that might be used in large team project.[8] A major advantage of this process is that testing of the application is completed continuously throughout development i.e. as soon as the first step of the application is designed it is fully tested and debugged before moving on to the next step. This approach also benefits project planning as the progress of the project can be monitored by how many parts and how many iterations of the RUP are completed weekly. This means more accurate estimations of the time required to develop parts of the application can be made, ensuring reasonable deadlines can be decided upon and met throughout.



4.2.1 System requirements The first step of any application development is the formulation of the requirement specifications, so to start, listed below in simple requirement statements are the main requirements of the system.

The experimental demonstration system that can show how the IEEE 1149.1(JTAG) standard can be used to develop in-system PCB tests shall:

Allow the user to utilise a GUI to interact with the JTAG Technologies board.


Allow the user to select a menu option on the GUI.

Allow a user to toggle switches that drive outputs and turn on LEDs in the GUI.

Interface via USB with the JTAG Technologies Board.

These are high level- requirements of the system. Please see Ch. 5 for a more detailed description of what is involved in each of these requirements.



Use cases are a formal way to capture and to express the interaction and dialog between system users (called actors) and the system itself. (Conallen 2000, pp.122) Use cases are useful in describing what a system should do without detailing how it should do it, and are used in this project to clearly identify what is required before implementation begins. The first task is to identify the actors of the system, of which there are two:



Shown in the following diagrams are use case diagrams that detail the interaction each of these actors will have with the system.


Figure 4-2: User Use Case Diagram

Figure 4-3: Administrator Use Case Diagram




USB 2.0


Device Under Test

Figure 4-4: System Snapshot

This design process is a sequence of steps that define a structured and predictable approach to the development of this application. If a process is structured, then we know what tasks must be completed. If a process is predictable, then we can estimate how long each task will take.


GUI Interface

Graphical user interfaces (GUIs) have become the user interface of choice. Yet despite the GUI's popularity, surprisingly few applications exhibit good interface design. Moreover, finding information explaining what constitutes a good and intuitive interface is exceedingly difficult

Successful GUIs share many common characteristics. Most importantly, good GUIs are more intuitive than their character-based counterparts. It is important that a graphical representation is immediately intuitive to users thus helping them learn the application faster. Another important characteristic of good GUIs is speed, or more specifically, responsiveness. Many speed issues are handled via the design of the GUI, not the hardware. Depending on the type of application, speed can be the make-or-break factor in determining an application's acceptability in the user community.


The GUI design brief for this project application is to mirror the PF2152 JTAG Technologies Experiment board. The implementation of this design is seen in Chapter 5. Designing a good GUI is a critical skill in this project. Good GUI design does not happen naturally. It required that the author learn and apply some basic principles, including making the design something the user will enjoy working with every day. It also required that the developer got as much experience as possible in working on and being exposed to good GUI designs. The ultimate aim of this project is that the user will have an easier time doing their job using the GUI this project accomplishes.

4.3.2 USB Interface Design of the USBInterface class was similar in design to the other software parts of the project but design best practices with DLL’s need to be obeyed.

The USBInterface calls three DLL’s

mpusbapi.dll- microchip DLL supplied with board

USBInterface.dll- C interface created by us in DLL form

cc3260mt.dll- Borland DLL downloaded from

A Dynamic Link Library is a library of executable functions and data that can be used by our GUI application. These DLL’s provide particular functions and the main program accesses these functions by creating a dynamic link to the DLL. A static link remains constant during program execution while a dynamic link is created by the program as needed.

4.3.3 Hardware The implementation of the hardware layout and design is detailed in Chapter 5.


Chapter 5: Implementation and Discussion





This section describes the specifics of the implementation of the system. Code snippets are given where appropriate to explain ideas. Full source code may be found in the Appendices and the accompanying CD-ROM.


GUI Menu Drop Down


Switches LEDs

SCAN 18541T

Bytes Sent

Bytes Received

Figure 5-1: Graphic User Interface


Figure 5-1 illustrates the GUI working in normal mode. To develop the GUI three classes were created;




The following is a description of the implementation for each of the classes.


The SwitchesPanel is located in west panel. This panel is broken into 2 further panels with gridlayout consisting of one single column with 2 rows containing two groupings of 7 checkboxes. Each of the check boxes has an action listener set of for it in the board class. Whenever one of the switches is checked the values of all the switches are read into an array of Booleans and then that array is passed to the led panel to update the display.


The LEDsPanel is located in east panel. This panel was then broken into 2 further panels with gridlayout consisting of single column with 2 rows. This contains two groupings of 7 labels which each have an image which represents the LED. When this is set to setOpaque(false) this means you can see the green background. This makes the panels background transparent and simulates the LED being on. A border space is created around the edge of the panel for aesthetics. A black border was also created around the outside. public void updateLEDs(boolean[] values), updates the labels with a text value and an image depending on whether the passed in Boolean value is true or false



A main method in the class is created so it can run from command line. A frame in which the GUI will be displayed is then created. This frame gets populated with the board class. Set exit_on_close to exit application on X is initialised. We then set size and show frame. BoardPanel is then set to border layout. We set background color to green. We then create switches panel and add it to the west panel of the frame. A centre panel is then created and set to the centre. The LEDs panel is then created and set it to the east.

private JPanel getCentrePanel() describes what will be displayed in the centre panel. We set centrepanel to borderlayout. This creates new optionsPanel which contains a drop down list for commands to north of centre panel. Two chip images are added to centre of centre panel. We then add labels for sent and place holder for value sent and received

We also add an action listener for the drop down box and add action listeners for each of the check boxes on the SwitchesPanel. Four cases are added to represent each of the values in the drop down that is selected. Finally we call down the USBInterface and update the value sent and received.



private static final String DEVICE_ID = "vid_04d8&pid_000b". This is a constant for bootload or demo mode.

We then load three DLLs: 

System.load("C:\\Documents and Settings\\franky\\jbProject\\USBInterface\\mpusbapi.dll"). This is a microchip DLL supplied with the PICDEM FS board.

System.load("C:\\Documents and Settings\\franky\\jbProject\\USBInterface\\USBInterface.dll"). This is the C interface created by us in a DLL.


System.load("C:\\Documents and Settings\\franky\\jbProject\\USBInterface\\cc3260mt.dll"). This is a Borland DLL downloaded form

private static native byte[] readWrite(String deviceName, int index, byte[] inputData, int inputSize, int bytesToRead, boolean debug). This calls our C code main used for testing independent of GUI.



We first wrote our java class with native methods i.e.: The USB Interface class. We then Ran javah in the command line over the USBInterface.class file. This creates a C header file USBInterface.h. The next task is to write a C file which has implementations for each of the prototypes defined in USBInterface.h.


standard Input/ Output

#include Standard #include "_mpusbapi.h" From the Board API #include "USBInterface.h" Our header Created file

/ Global Vars char out_pipe[]= "\\MCHP_EP1"; This is a unique identifier to write out char in_pipe[]= "\\MCHP_EP1"; This is a unique identifier to read in

void print(bool debug, char *text);

This describes debugging to print out whats going

on in the C code.

JNIEXPORT jint JNICALL Java_USBInterface_getVersionNumber (JNIEnv *env, jclass)


{ jint version = MPUSBGetDLLVersion(); return version; }

This is the Call to API to test the C code could connect to the DLL.

BYTE * convert(JNIEnv *env, jbyteArray value, int sizeOfArray) { BYTE* result = (char *) malloc(sizeof(BYTE)*sizeOfArray); env->GetByteArrayRegion(value, 0, sizeOfArray, result);

return result; }

This code converts jbyte array into a c type.

BYTE* receiveBuf = (char *) malloc(sizeof(BYTE)*bytesToRead); This creates space for the bytes to be returned as a result.

HANDLE out = MPUSBOpen(index, id, out_pipe, MP_WRITE, 0);

HANDLE in = MPUSBOpen(index, id, out_pipe, MP_READ, 0); This opens output and input streams to the board.

if (MPUSBWrite(out, bytes, inputSize, &bytesSent, 1000)); This writes the command that we passed into the C program to the board.

if (MPUSBRead(in, receiveBuf, bytesToRead, &bytesRead, 1000)); This code reads the results from the board and puts them into the byte array.


MPUSBClose(in); MPUSBClose(out); This Closes both pipes



The function Test_Logic_reset was added to the C code. This is detailed further in Chapter 2-3 and in the appendices. This function was added to the sample code given with the CD. This code was then compiled using MPLAB IDE v7.31 and bootloaded to the microcontroller on the PICDEM FS USB board using the PICDEM FS USB Demo Tool.

Figure 5-2: PICDEM FS USB Demo Tool




Figure 3-8 and Appendix 2 detail the correct connection for the jumper header and cabling. We soldered a jumper to the PICDEM FS USB Board and connected it to the PF2152 via cable.

Jumper Positions:

RBO – J1/1 RB1 – J1/3 RB2 – J1/5 RB3 – J1/7

The cabling positions are detailed below:

#define TCK


#define TMS


#define TDO_PIC


#define TDI_PIC


An oscilloscope was then connected across GND and RBO to show a rising edge TCK.



Because of the iterative design approach used in this project testing began as soon as the first step was implemented. Essentially, as soon as a new step was finished or a new feature was added the project was recompiled and run from whatever environment the changes were made to.







The ‘Demonstration system that can show how the IEEE 1149.1(JTAG) standard can be used to develop in-system PCB tests’ developed during this project demonstrates the successful analysis, design and implementation of such an application. It is hoped the system created may enhance the learning experience of a user by providing them with this powerful tool. The system provides a user friendly experience and an enabling learning environment.

The project implements some of the latest technologies used to develop such an application such as Java, C, C++, DLLs, Boundary Scan, IDEs etc. The broad range of technologies implemented gives a good insight into the changing world of hardware and software technologies and how they interoperate with each other.

The project has been a worthwhile educational experience blending a mix of Hardware, Test and Software Engineering. Although areas of difficulty did occur, Trial, Error and perseverance ensured these were overcome.


The author is satisfied that the criteria set down at the outset of the project has been fulfilled and ultimately the project has been a success.



The entire system provides a good foundation from which to build a robust, reusable tool for both students and teachers alike. The application requires some rigorous testing in a live setting for a more realistic evaluation as improvements and suggestions from the end user would help improve the application. Evaluation of the system under different conditions and stresses would give a clearer indication of its worth.

From a developers perspective there are a few areas that could be addressed. An online user interface could be implemented with more JTAG functions being simulated and stepped through.

This project could be extended to provide an IDE for a set of test demo programs using the same PF 2152 JTAG demo board.

This project could also be extended to support a number of different languages so that it could be used in non- English speaking countries.





[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

J. Axelson, USB Complete: Everything you need to know to develop USB peripherals, Third ed: Lakeview Research, 2005. J. Technologies, When does Boundary-Scan make sense, First ed: JTAG Technologies, 2005. IEEE, "IEEE Std 1149.1; IEEE Standard Test Access Port and Boundary-Scan Architecture," 2001. K. P. Parker, The Boundary- Scan Handbook, Third ed: Kluwer Academic Publishers, 2003. Borland, "User Guide: Getting Started with JBuilder," 2004. Microchip, "MPLAB® IDE Users Guide," 2005. JTAG, "Application Development Packages, Users Guides," 2004. Conallen, Building Applications with UML, 2000. Microchip, "PICDEM™ FS USB Demonstration Board Users Guide," 2004. B. Eckel, Thinking Java, 3rd Edition ed, 2004.





Appendix 1


GUI Board Class /** * Title:FYP * * Description:Implementation of JTAG (IEEE 1149.1) demo system combined with a set of test programs GUI * * Copyright: Copyright (c) 2006 * * Company:UL Student Frank Leonard * * @Frank * @version 1.0 */

import java.awt.BorderLayout; import java.awt.Color; import java.awt.FlowLayout; import java.awt.GridLayout; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import javax.swing.ImageIcon; import javax.swing.JComboBox; import javax.swing.JFrame; import javax.swing.JLabel; import javax.swing.JPanel; import javax.swing.border.EmptyBorder; /** * @author Frank Leonard */ public class Board extends JPanel { public static void main(String[] args) { JFrame frame = new JFrame(); Board panel = new Board(); frame.getContentPane().add(panel); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setSize(350, 350);; } private SwitchesPanel switchesPanel;


private LEDsPanel ledsPanel; private JComboBox comboBox; private JLabel commandSent; private JLabel commandReceived; public Board() { initialize(); } private void initialize() { setLayout(new BorderLayout()); setBackground(new Color(0, 128, 0)); switchesPanel = new SwitchesPanel(); add(switchesPanel, BorderLayout.WEST); add(getCentrePanel(), BorderLayout.CENTER); ledsPanel = new LEDsPanel(); add(ledsPanel, BorderLayout.EAST); } private JPanel getCentrePanel() { JPanel panel = new JPanel(new BorderLayout()); panel.setOpaque(false); JPanel optionsPanel = new JPanel(new FlowLayout(FlowLayout.LEFT)); optionsPanel.setOpaque(false); String[] options = {"Verify JTAG present", "Read Switches", "Count Down LEDS", "Test"}; comboBox = new JComboBox(options); optionsPanel.add(comboBox); panel.add(optionsPanel, BorderLayout.NORTH); JPanel centrePanel = new JPanel(new GridLayout()); centrePanel.setBorder(new EmptyBorder(10, 10, 10, 10)); centrePanel.setOpaque(false); JLabel chip1 = new JLabel(new ImageIcon("C:\\Documents and Settings\\franky\\FYP\\images\\chip.png")); centrePanel.add(chip1); centrePanel.add(new JLabel());


JLabel chip2 = new JLabel(new ImageIcon("C:\\Documents and Settings\\franky\\FYP\\images\\chip.png")); centrePanel.add(chip2); panel.add(centrePanel, BorderLayout.CENTER); JPanel bottomPanel = new JPanel(); bottomPanel.setOpaque(false); JLabel cmdLabel = new JLabel("Sent:"); bottomPanel.add(cmdLabel); commandSent = new JLabel(); bottomPanel.add(commandSent); JLabel rcLabel = new JLabel("Received:"); bottomPanel.add(rcLabel); commandReceived = new JLabel(); bottomPanel.add(commandReceived); panel.add(bottomPanel, BorderLayout.SOUTH); registerForEvents(); return panel; } private void registerForEvents() { comboBox.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { selectionMade(); } }); for (int i=0; i < switchesPanel.switches.length; i++) { switchesPanel.switches[i].addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { ledsPanel.updateLEDs(switchesPanel.getValues()); } }); } }


private void selectionMade() { int index = comboBox.getSelectedIndex(); byte[] input = null; switch (index) { case 1: input = new byte[2]; input[0] = 0; input[1] = 38; break; case 2: input = new byte[2]; input[0] = 0; input[1] = 39; break; case 3: input = new byte[2]; input[0] = 0; input[1] = 40; break; default: input = new byte[2]; input[0] = 0; input[1] = 41; } commandSent.setText("" + input[0] + input[1]); try { byte[] received = USBInterface.readWrite(USBInterface.DEVICE_ID, 0, input, input.length, 8, true); if (received != null) { StringBuffer strBuf = new StringBuffer(); for (int i = 0; i < received.length; i++) { strBuf.append(received[i]); } commandReceived.setText(strBuf.toString()); } } catch (Throwable e) { e.printStackTrace(); }


} }

GUI LEDsPanel Class /** * Title:FYP * * Description:Implementation of JTAG (IEEE 1149.1) demo system combined with a set of test programs GUI * * Copyright: Copyright (c) 2006 * * Company:UL Student Frank Leonard * * @author Frank Leonard * @version 1.0 */ import java.awt.Color; import java.awt.GridLayout; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import; import; import javax.swing.ImageIcon; import javax.swing.JButton; import javax.swing.JFrame; import javax.swing.JLabel; import javax.swing.JPanel; import javax.swing.SwingConstants; import javax.swing.border.EmptyBorder; import javax.swing.border.LineBorder; /** * @author Frank Leonard */ public class LEDsPanel extends JPanel { private static final int LEDS_PER_PANEL = 7; private JLabel[] leds = new JLabel[LEDS_PER_PANEL * 2]; public LEDsPanel() {


initialize(); } /* * Create a panel containing 7 switchs in a column. */ private JPanel createLEDPanel(int offset, boolean[] values) { JPanel ledPanel = new JPanel(); ledPanel.setBorder(new EmptyBorder(5, 5, 5, 5)); ledPanel.setOpaque(false); JPanel panel = new JPanel(new GridLayout(LEDS_PER_PANEL, 1)); panel.setBorder(new LineBorder(; for (int i = 0; i < LEDS_PER_PANEL; i++) { JLabel label = new JLabel(); leds[i + offset] = label; panel.add(label); } ledPanel.add(panel); return ledPanel; } private void initialize() { setLayout(new GridLayout(2, 1)); setOpaque(false); add(createLEDPanel(0, new boolean[LEDS_PER_PANEL])); add(createLEDPanel(LEDS_PER_PANEL, new boolean[LEDS_PER_PANEL])); updateLEDs(new boolean[LEDS_PER_PANEL *2]); } public void updateLEDs(boolean[] values) { for (int i = 0; i < leds.length; i++) { ImageIcon icon = null; String text = null; if (values[i]) { text = "on";


icon = new ImageIcon("C:\\Documents and Settings\\franky\\jbProject\\FYP\\images\\LED_on.png"); } else { text = "off"; icon = new ImageIcon("C:\\Documents and Settings\\franky\\jbProject\\FYP\\images\\LED_off.png"); } leds[i].setText(text); leds[i].setIcon(icon); } } }

GUI SwitchesPanel Class /** * Title:FYP * * Description:Implementation of JTAG (IEEE 1149.1) demo system combined with a set of test programs GUI * * Copyright: Copyright (c) 2006 * * Company:UL Student Frank Leonard * * @author Frank Leonard * @version 1.0 */ import java.awt.Color; import java.awt.GridLayout; import java.awt.LayoutManager; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import javax.swing.JCheckBox; import javax.swing.JPanel; import javax.swing.border.EmptyBorder; import javax.swing.border.LineBorder; /**


* @author Frank Leonard * */ public class SwitchesPanel extends JPanel { /** * Number of switches in each grouping */ public static final int SWITCHES_PER_PANEL = 7; public JCheckBox[] switches = new JCheckBox[SWITCHES_PER_PANEL * 2]; /** * */ public SwitchesPanel() { initialize(); } /* * Create a panel containing 7 switchs in a column. */ private JPanel createSwitchesPanel(int offset) { JPanel switchPanel = new JPanel(); switchPanel.setBorder(new EmptyBorder(2, 5, 5, 2)); switchPanel.setOpaque(false); JPanel panel = new JPanel(new GridLayout(SWITCHES_PER_PANEL, 1)); panel.setBorder(new LineBorder(Color.BLACK)); for (int i = 0; i < SWITCHES_PER_PANEL; i++) { JCheckBox checkBox = new JCheckBox(); switches[i + offset] = checkBox; panel.add(checkBox); } switchPanel.add(panel); return switchPanel; } /** * Get the values of all the switches * @return */


public boolean[] getValues() { boolean[] values = new boolean[switches.length]; for (int i = 0; i < switches.length; i++) { values[i] = switches[i].isSelected(); } return values; } /* * Setup the components to be shown on the panel */ private void initialize() { setLayout(new GridLayout(2, 1)); setOpaque(false); add(createSwitchesPanel(0)); add(createSwitchesPanel(SWITCHES_PER_PANEL)); } }

USBInterface Class /** * Title: FYP USBInterface * * Description: USBInterface * * Copyright: Copyright (c) 2006 * * Company: UL * * @ UL Student Frank Leonard * @version 1.0 */

public class USBInterface { //

public static final String DEVICE_ID = "vid_04d8&pid_000b"; // boot load mode public static final String DEVICE_ID = "vid_04d8&pid_000c"; // demo mode static {


try { // // //

System.loadLibrary("cc3260mt"); System.loadLibrary("mpusbapi"); System.loadLibrary("USBInterface"); System.load("C:\\Documents and Settings\\franky\\fyp\\mpusbapi.dll"); System.load("C:\\Documents and Settings\\franky\\fyp\\USBInterface.dll"); System.load("C:\\Documents and Settings\\franky\\fyp\\cc3260mt.dll"); } catch (Throwable e) { e.printStackTrace(); System.exit(1); } } /** * Get the version number of the MPUSBAPI that is being used * @return */ public static native int getVersionNumber(); /** * Read a number of bytes from a specified USB device * @param numberOfBytes * @return */ private static native byte[] read(String deviceName, int index, int numberOfBytes, boolean debug); /** * Write the passed array of bytes to the USB device specified * @param data */ private static native void write(String deviceName, int index, byte[] input, int inputSize, boolean debug); /** * Write and then read from the USB device in the one call * @param deviceName * @param index * @param inputData * @param bytesToRead * @param debug */ public static native byte[] readWrite(String deviceName, int index, byte[] inputData, int inputSize, int bytesToRead, boolean debug);


/** * Test calling the native methods to ensure they work correctly. * @param args */ public static void main(String[] args) { // for (int i = 0; i < args.length; i++) { // System.loadLibrary(args[i]); //} System.out.println("Starting Write/Read"); int value = getVersionNumber(); /* value = 65538; System.out.println((value >> 16) + "." + ((value > 16)); byte[] bytes = {(byte) 38, (byte)2}; write(DEVICE_ID, 0, bytes, bytes.length, true); byte[] cbytes = read(DEVICE_ID, 0, 32, true); for (int i = 0; i < cbytes.length; i++) { System.out.println(cbytes[i]); } */ byte[] input = {(byte)0, (byte)38}; byte[] rb = readWrite(DEVICE_ID, 0, input, input.length, 8,true); for (int i = 0; i < rb.length; i++) { System.out.print(rb[i]); } System.out.println("\nFinished Write/Read"); } /* * Get the value of the lower 16-bits of the passed int * @param aValue * @return */ private int getLowerBits(int aValue) { return aValue >> 16 > 16; }



C Code #include #include #include "_mpusbapi.h" #include "USBInterface.h" #pragma argsused // Global Vars char out_pipe[]= "\\MCHP_EP1"; char in_pipe[]= "\\MCHP_EP1"; DWORD temp; HANDLE myOutPipe; HANDLE myInPipe; // ------------------------------------------------// Prototypes void print(bool debug, char *text); void print(bool debug, char *text, int value); void print(bool debug, char *text, const char *value); void print(bool debug, char *text, void *value); char* convert(JNIEnv *env, jstring value); BYTE* convert(JNIEnv *env, jbyteArray value, int sizeOfArray); // ------------------------------------------------/* * Library method to be called by Java program to get the version number */ JNIEXPORT jint JNICALL Java_USBInterface_getVersionNumber (JNIEnv *env, jclass) { jint version = MPUSBGetDLLVersion(); return version; } /* * Convert the passed jbyteArray to a BYTE* */


BYTE * convert(JNIEnv *env, jbyteArray value, int sizeOfArray) { BYTE* result = (char *) malloc(sizeof(BYTE)*sizeOfArray); env->GetByteArrayRegion(value, 0, sizeOfArray, result); return result; } /* * Convert the passed jstring to a char* */ char* convert(JNIEnv *env, jstring value) { const char* id = env->GetStringUTFChars(value, JNI_FALSE); const char *temp = id; int size = 0; while(*temp++ != 0) { size++; } char* result = (char*) malloc(sizeof(char)*size); memcpy(result, id, size); return result; } /* * Library method to be called by Java program to get the read the state of the board */ JNIEXPORT jbyteArray JNICALL Java_USBInterface_read (JNIEnv *env, jclass, jstring deviceId, jint index, jint bytesToRead, jboolean debug) { print(debug, "\n\nOpening connection for read\n", 0); long size = bytesToRead; print(debug, "Number of bytes to read = %d\n", size); BYTE* bytes = (char *) malloc(sizeof(BYTE)*bytesToRead); DWORD bytesRead = 0; char* id = convert(env, deviceId);


print(debug, "Accessing device: %s\n", id); HANDLE in = INVALID_HANDLE_VALUE; in = MPUSBOpen(index,id, in_pipe,MP_READ,0); if(in != INVALID_HANDLE_VALUE) { print(debug, "Attempting to read bytes\n"); DWORD success = MPUSBRead(in, &bytes, size, &bytesRead, 0); print(debug, "Success: %d\n", success); if (success == 1) { int size = LOWORD(bytesRead); print(debug, "Bytes read = %d", size); } MPUSBClose(in); print(debug, "Closed read connection\n"); } env->ReleaseStringUTFChars(deviceId, id); print(debug, "About to create jbyteArray\n"); jbyteArray jbytes = env->NewByteArray(bytesRead); print(debug, "Create jbyteArray[%d]\n", bytesRead); env->SetByteArrayRegion(jbytes, 0, bytesRead, (jbyte *)bytes); print(debug, "Set the values read from board to jbyteArray\n"); return jbytes; } /* * Library method to be called by Java program to set the state of the board */ JNIEXPORT void JNICALL Java_USBInterface_write (JNIEnv *env, jclass, jstring deviceId, jint index, jbyteArray input, jint inputSize, jboolean debug) { print(debug, "\n\nOpening connection for write\n"); HANDLE out = INVALID_HANDLE_VALUE; char* id = convert(env, deviceId);


BYTE* bytes = convert(env, input, inputSize); print(debug, "Accessing device: %s\n", id);

out = MPUSBOpen(index, id, out_pipe, MP_WRITE,0); print(debug, "Checking handle to pipe: %d\n", out); if(out != INVALID_HANDLE_VALUE) { DWORD bytesSent; print(debug, "Opened write connection\n"); MPUSBWrite(out, bytes, inputSize, &bytesSent, 1000); print(debug, "Number of bytes written: %d\n", bytesSent); MPUSBClose(out); print(debug, "Closed write connection\n"); } print(debug, "Releasing the UTFChars\n"); env->ReleaseStringUTFChars(deviceId, id); print(debug, "UTFChars released\n"); } JNIEXPORT jbyteArray JNICALL Java_USBInterface_readWrite (JNIEnv *env, jclass, jstring deviceId, jint index, jbyteArray input, jint inputSize, jint bytesToRead, jboolean debug) { print(debug, "\n\nOpening connection for read and write\n"); unsigned long bytesRead = 0; BYTE* receiveBuf = (char *) malloc(sizeof(BYTE)*bytesToRead); char* id = convert(env, deviceId); print(debug, "Accessing device: %s\n", id); HANDLE out = MPUSBOpen(index, id, out_pipe, MP_WRITE, 0); HANDLE in = MPUSBOpen(index, id, out_pipe, MP_READ, 0); BYTE* bytes = convert(env, input, inputSize); if (out == INVALID_HANDLE_VALUE || in == INVALID_HANDLE_VALUE) { print(debug, "Failed to open pipes\n"); } else { unsigned long bytesSent;


if (MPUSBWrite(out, bytes, inputSize, &bytesSent, 1000)) { print(debug, "Wrote %d btyes\n", bytesSent); if (MPUSBRead(in, receiveBuf, bytesToRead, &bytesRead, 1000)) { print(debug, "Read %d bytes\n", bytesRead); } else { print(debug, " - Failed to read bytes\n"); } } else { print(debug, "Failed to write bytes to pipe\n"); } MPUSBClose(in); MPUSBClose(out); } env->ReleaseStringUTFChars(deviceId, id); print(debug, "About to create jbyteArray\n"); jbyteArray result = env->NewByteArray(bytesRead); print(debug, "Create jbyteArray[%d]\n", bytesRead); env->SetByteArrayRegion(result, 0, bytesRead, (jbyte *)receiveBuf); print(debug, "Set the values read from board to jbyteArray\n"); return result; } void print(bool debug, char *value) { if (debug) { printf(value); } }

void print(bool debug, char *value, int param) { if (debug) { printf(value, param);


} } void print(bool debug, char *value, const char *param) { if (debug) { printf(value, param); } } void print(bool debug, char *value, void *param) { if (debug) { printf(value, param); } }

Test Logic Reset Function /*********************************************************************** ******* * Function: Test_Logic_Reset * * PreCondition: None * * Input: None * * Output: None * * Side Effects: None * * Overview: Addition to code from FYP Meeting 31/3 * * Note: None ****************************************************************** ***********/ void Test_Logic_Reset(){

int TLR_count; TRISB=0x8; TCK=1;


TMS=1; TDO_PIC=1; WRITE_DETECT=1; PORTB=0x7; for (TLR_count=0; TLR_count