Student: Matthew Youd c2005240 Project: J T AG Hardware Debugger

Student: Matthew Youd c2005240

Project: JTAG Hardware Debugger

University supervisor: Siew Wah Chan

Industry supervisor: Steve Neave

Industry sponsor: Serck Controls Pty Ltd

JTAG Hardware Debugger - Final Report

Matthew Youd c2005240 i

1 Abstract

In industry the cost of finding faults on circuit boards increases exponentially as fault finding

moves from one level of complexity to the next. The later it is found in the design-

manufacturing-field process the higher the cost. As a result the earlier the testing is conducted

and the more thorough it is, the better.

The aim of my project was to create a hardware debugger capable of testing for hardware faults

on circuit boards. This would be accomplished using the IEEE 1149.1 Standard, 'Test Access Port

and Boundary-Scan Architecture'. This standard was developed by the Joint Test Action Group or

JTAG.

The primary aim was to develop a hardware tester that would utilise the boundary scan

compatible components present on the board and then provide the operator with a Pass or Fail

report. The interface will be accomplished between Personal Computer and Test Circuit Board

via the Parallel port of a PC.


Matthew Youd c2005240 ii

2 Contents

1 Abstract ................................................................................................................................... i

2 Contents.................................................................................................................................. ii

3 List of Figures ....................................................................................................................... iv

4 List of Tables.......................................................................................................................... v

5 Introduction ........................................................................................................................... 1

5.1 Serck Controls................................................................................................................ 1

5.1.1 SCADA...................................................................................................................... 2

5.1.2 RTU ........................................................................................................................... 2

5.2 Current Testing Methods ............................................................................................... 3

6 Technical Background .......................................................................................................... 4

6.1 JTAG and Boundary Scan.............................................................................................. 4

6.1.1 Background................................................................................................................ 4

6.1.2 JTAG ......................................................................................................................... 5

6.1.3 Boundary Scan........................................................................................................... 5

6.1.4 Chip Architecture....................................................................................................... 6

6.1.5 TAP Controller .......................................................................................................... 8

6.1.6 Mandatory Instructions.............................................................................................. 9

6.2 Faults on Circuit Boards ................................................................................................ 9

7 Hardware ............................................................................................................................. 11

7.1 Cable Interface ............................................................................................................. 11

7.1.1 Parallel cable III....................................................................................................... 11

7.1.2 Final Cable Used ..................................................................................................... 14

7.2 The Parallel Port........................................................................................................... 14

7.2.1 Pin Assignments ...................................................................................................... 15

7.3 Circuit Boards .............................................................................................................. 15

7.4 Digilab XC2 ................................................................................................................. 16

7.5 Flash Memory Socket .................................................................................................. 22

7.6 Serck Controls Circuit Boards ..................................................................................... 23

7.6.1 386 eNET................................................................................................................. 23

7.6.2 586 eNET................................................................................................................. 24

8 Software................................................................................................................................ 25

8.1 Code Language ............................................................................................................ 25


Matthew Youd c2005240 iii

8.2 Interfacing with the Parallel Port ................................................................................. 25

8.3 Software Design & Implementation............................................................................. 26

8.4 Testing structure........................................................................................................... 27

8.5 Flash Memory Test ...................................................................................................... 30

9 Results................................................................................................................................... 32

10 Conclusion....................................................................................................................... 35

11 Bibliography ................................................................................................................... 36


Matthew Youd c2005240 iv

3 List of Figures

Figure 1 Boundary Scan Path .......................................................................................................... 6

Figure 2 Chip Architecture.............................................................................................................. 7

Figure 3 Identification Register....................................................................................................... 7

Figure 4 TAP Controller State Diagram.......................................................................................... 8

Figure 5 Boundary scan test coverage........................................................................................... 10

Figure 6 Parallel Cable III ............................................................................................................. 12

Figure 7 Cable Schematic.............................................................................................................. 13

Figure 8 Parallel Port..................................................................................................................... 15

Figure 9 XC2 Block Diagram........................................................................................................ 17

Figure 10 Parallel port connectors and signals.............................................................................. 17

Figure 11 Signal routing to expansion connectors ........................................................................ 18

Figure 12 Modified Digilab XC2 Board ....................................................................................... 19

Figure 13 Demonstration Circuit................................................................................................... 20

Figure 14 Serck Controls eNET RTU ........................................................................................... 23

Figure 15 Interconnect Test Example (a) ...................................................................................... 28

Figure 16 Interconnect Test Example (b)...................................................................................... 29

Figure 17 Interconnect Test Example (c) ...................................................................................... 29

Figure 18 Interconnect Test Example (d)...................................................................................... 30

Figure 19 Flash Memory address and data lines ........................................................................... 31

Figure 20 Windows Interface ........................................................................................................ 32


Matthew Youd c2005240 v

4 List of Tables

Table 1 Parallel Cable III pin assignments.................................................................................... 15

Table 2 Board Pin out assignments ............................................................................................... 21


Matthew Youd c2005240 1

5 Introduction

My Final Year Project was offered to me from my current employer Serck Controls. Serck

Controls produce their own RTU’s (Remote Telemetry Unit). These RTU’s are currently

thoroughly tested for hardware faults in the first stages of production. In later stages of production

as components are installed the hardware testing is more difficult and time consuming. This has

been identified as an area that can be improved.

My Project utilises the IEEE Standard 1149.1-2001 “Test Access Port and Boundary-Scan

Architecture”, developed by the Joint Test Action Group (or JTAG) started in the mid 80’s. I

have created a Boundary Scan test that successfully finds faults and identifies them on my circuit

board. My software applies test vectors as stimulus to interconnections between devices.

Applying several test vectors enables me to determine whether any physical faults exist.

My primary aim was to have a working test that will produce a pass or fail report. I have

achieved this and in addition my report will indicate where the fault was located and suggest what

type of fault it is.

Further to testing hardware interconnections for faults my test also accesses a flash memory chip

I added to the board. By reading and writing to several different locations I am able to indirectly

test the address and data lines.

My JTAG hardware debugger has not only demonstrated to the hardware design engineers at

Serck Controls the possibilities for Boundary Scan testing on Serck controls custom hardware but

also demonstrated that it is possible to program the Flash Memory from the JTAG port on the

board. There are significant advantages from this described in detail later in the report, it is

something Serck Controls have indicated they will be taking advantage of in the very near future.

5.1 Serck Controls

Serck Controls is a process control and engineering company whose main activity is the design

and manufacture of remote telemetry systems. This is achieved by using their advanced range of

SCADA and control software with highly resilient, programmable remote telemetry units and



controllers. Serck Controls currently manufactures a range of RTU’s including the eNET, PX24,

MGX, �MGX and PDS.

Serck Controls is a global organisation with offices not only throughout Australia but also in

Coventry, Luton, Saudi Arabia, Dubai, Abu Dhabi, Beijing, and Mumbai. Serck Controls head

office is in Cardiff, Newcastle, and recently expanded into a second office in Cardiff.

5.1.1 SCADA

SCADA stands for Supervisory Control and Data Acquisition. SCADA is a system used to

electronically monitor (including the ability to trend data and generate regulatory reports) and

control remote operations from a central point. For example, a SCADA system can be used to

control and monitor the status of a remote pumping facility from a water or wastewater facility. A

SCADA system consists of five major components: master computer, software, communication

link, remote terminal and input/output devices.

Serck Controls has its own SCADA Software called SCX6. This software is state of the art with

many features such as:

• Embedded web technology

• Wide use of open standards

• Advanced trend facilities

• Streamline configuration

As an employee at Serck Controls since 2003, my main area of work has been with the SCX6

SCADA side of our projects.

Serck Controls also manufactures its own RTU’s. Described in the next section 5.1.2, Serck has a

wide range of advanced hardware products and it is this part of Serck Controls that my project

will be focused.

5.1.2 RTU

RTU stands for Remote Telemetry Unit. Serck has a wide range of products including the eNET,

PX24, MGX, �MGX and PDS. My project will demonstrate what in the future could be

integrated into the production of the eNET RTU. The eNET Series is the newest member of



Serck Controls range of outstations providing new industry benchmarks for functionality and

cost.

There are two versions available, the 386-eNET and the 586-eNET, which have different

processors for different applications. Both eNETs have a JTAG port that I would be able to

interface to. The 386-eNET however has only one device on the JTAG chain, for this reason only

the 586-eNET would be suitable at the moment for possible JTAG hardware debugging

programs.

Both eNETs however have a ROM which as described in section 2.2, this can also be tested and

possibly programmed. There are significant advantages of programming the ROM via the JTAG

port that are also described in section 7.5.

5.2 Current Testing Methods

Currently Serck Controls have their boards manufactured and tested using the bed-of-nails

technique, (bed-of-nails described below in section 6.1.1). After this stage the devices are then

installed on the board. After the devices are installed, firmware is loaded and some further

functionality testing is conducted. This testing will usually pick up any major problems or faults

however it does not test everything. This stage of testing can be time consuming as any faults

detected need to be tracked down. It is possible that using a JTAG hardware debugger could

improve this process and make it more thorough.

Serck Controls performs further testing than that described here but in terms of the scope of my

project only the testing described above is relevant.



6 Technical Background

6.1 JTAG and Boundary Scan

My Project utilises the IEEE Standard 1149.1-2001 “Test Access Port and Boundary-Scan

Architecture”, developed by the Joint Test Action Group (or JTAG). Below describes in more

detail who JTAG are and how Boundary Scan works.

6.1.1 Background

Previously, since the mid 1970’s, the structural testing of loaded printed circuit boards has relied

very heavily on the use of the so-called in-circuit bed-of-nails technique. This method of testing

makes use of a fixture containing a bed-of-nails to access individual devices on the board through

test lands laid into the copper interconnects.

Testing would involve two phases, power off tests followed by power on tests. Power off tests

check the integrity of the physical contact between nail and the on-board access point, followed

by open and shorts tests based on impedance measurements. Power on tests apply stimulus to a

chosen device, or collection of devices, with an accompanying measurement of the response from

that device. In this way it is possible to check the presence, orientation and bonding of the devices

on the board.

This technique relies on physical access to all devices on a board. As technology progressed and

we saw the emergence of surface mount packaging and multilayer boards, the ability to

physically probe onto the board with a bed of nails system was going away, physical access was

becoming limited.[1]

In fact the fault coverage provided by bed-of-nails in-circuit testers peaked at around 97% to 98%

in the late 1980s and early 1990s. Since then fault coverage using these testers has been in general

decline and by the late 1990’s was falling rapidly [2].



6.1.2 JTAG

This was the situation in the mid 1980’s. A group of concerned test engineers in a number of

European electronics systems companies got together to examine the board test problem. The

group initially called themselves the Joint European Test Action Group (JETAG). There method

of solution was to bring back access to device pins by means of an internal serial shift register

around the boundary of the device, a boundary scan register.[1]

The group was later renamed to the Joint Test Action Group, JTAG, after representatives from

North America joined. Several Companies were already working on this idea, JTAG converted

these ideas into an international standard. The IEEE 1149.1-1990 Standard, first published in

April 1990.

6.1.3 Boundary Scan

For a boundary scan path to exist there must be 1 or more boundary scan devices on a board

(Figure 1). In a boundary scan device, each input or output signal is supplemented with a

multipurpose memory element called a boundary scan cell. This collection of boundary scan

cells is configured into a shift register. A load instruction called a Capture operation causes

signal values on a device input pin to be loaded into the boundary scan cell, and signal values

passing from the internal logic device output pins to be loaded in the boundary scan cell. An

Update operation causes signal values already present in output scan cells to be passed out

through the device output pins, signals present in input scan cells are passed through into the

internal logic.

Data can be shifted around the shift register, in serial mode, starting from the Test Data In (TDI)

input pin and terminating at the Test Data Out (TDO) output pin. The Test Clock (TCK) is fed

by another dedicated device input pin and the various modes of operation are controlled by the

Test Mode Select (TMS) serial control signal.



Figure 1 Boundary Scan Path

6.1.4 Chip Architecture

After nearly five year’s discussion, the JTAG organization proposed the device architecture

shown in Figure 2. The figure shows the following elements:

• A set of four dedicated test pins – Test Data In (TDI), Test Mode Select (TMS),

Test Clock (TCK), Test Data Out (TDO), and the optional Test Reset (TRST*).

These pins are collectively referred to as the Test Access Port (TAP)

• A boundary scan cell on each device primary input and primary output pin,

connected internally to form a serial boundary scan register

• A finite state machine TAP controller with inputs TCK, TMS, and TRST*.

• An n-bit (n>=2) instruction register, holding the current instruction.

• A 1-bit Bypass register.

• An optional 32-bit identification register capable of being loaded with a

permanent device identification code.



Figure 2 Chip Architecture

Figure 3 Identification Register

The 32 bit Identification register, as shown above, has useful properties that I will take advantage

of with my testing structure. The LSB is always ‘1’, and bits 1-7 of the Manufacturer Identity

cannot be all 1’s.



6.1.5 TAP Controller

Figure 3 shows the 16-state table for the TAP controller. The value on the state transition arcs is

the value of TMS. A state transition occurs on the positive edge of TCK and the controller output

values change on the negative edge of TCK.

The TAP controller initializes in the Test Logic Reset state.

Figure 4 TAP Controller State Diagram



6.1.6 Mandatory Instructions

There are several mandatory instructions, these are, Extest, Bypass, and Sample/Preload.

EXTEST

When the Extest instruction is executed the boundary-scan register is selected. Values are

‘captured’ on the input pins and values ‘updated’ on the output pins.

BYPASS

The code for the Bypass instruction is all 1’s. When executed the bypass register is selected

between the TDI and TDO pins.

SAMPLE and PRELOAD

The Sample and Preload instructions select the Boundary scan register when executed. The

sample or capture instruction, captures the input values into the corresponding boundary scan

cell.

6.2 Faults on Circuit Boards

There is any number of faults that could occur during the lifecycle of any piece of hardware.

These include, design errors, incorrect hardware, damaged hardware, incorrectly installed

hardware, bonding faults, etc These defects can be caused from electrical stress (e.g. electrostatic

discharge), mechanical stress (e.g. bent legs caused by clumsy handling), or thermal stress (e.g.

hot spots caused by soldering).

Boundary Scan testing can detect and test the presence, orientation, and bonding of devices on a

printed circuit board. Some of the most common and hard to find faults can be bonding faults,

often caused by poor or missing solder joins. Faults such as opens and shorts on the tracks

between devices can be detected and located using boundary scan testing.

Because boundary scan test vectors are generated and received from inside the chips on a board,

faults can be determined on the interconnections between inputs and outputs as well as faults in



the bonding of the chip to the tracks or contacts. The following figure illustrates this complete

test path.

Figure 5 Boundary scan test coverage

My 2005 Final Year project does not only test for faults between devices but also attempts to

determine whether the fault is an OPEN or a SHORT, and indicate where on the board the fault

was identified.



7 Hardware

Hardware has proven to be one of the more difficult and challenging aspects of my project.

Whether it was the physical cable to interface my PC and circuit board or the actual circuit board

itself I have had many hardware obstacles to overcome.

Detailed in this chapter, I will describe the work done to interface to my circuit board and then

describe the many challenges with circuit boards. While I initially assumed the project would

involve little hardware design or interactions, I was proven wrong and spent a lot of ‘hands on

time’, whether it was soldering or reading hardware manuals and schematics. As a result this

project proved to be a very well balanced and interesting experience.

7.1 Cable Interface

During the different stages of my project I have had different obstacles to overcome, one of the

first was to interface from my PC to the circuit boards I was using. To begin with I was given a

386 eNET RTU (see section 7.3 for more RTU information). To interface with this I had to have

a cable to go from my PC parallel port to the JTAG port of the circuit board. Described in the

following section, this cable later had to be modified so I could connect to the 586 eNET.

As fate had it both eNETs were not suitable for my project. Due to the complexity of the

hardware platform it was not suitable for a prototype tester. I later obtained a Digilab XC2 circuit

board that had a DB 25 port so in the end I now use a simple and common printer cable.

7.1.1 Parallel cable III

In the early stages of my project, finding a cable capable of allowing me to interface was a

challenge. There were three main things I had to consider:

• Cost – Many cables were very expensive

• Usability – There were some cables designed to be used with third party

software. Custom use of the cable was not a necessarily possible as there were

vender specific protocols used which had no available documentation.



• Protection – I needed a cable that had some in built protection to protect my PC

motherboard and parallel port.

Fortunately Serck Controls had a Parallel cable III in stock. This cable is no longer advertised as a

product for sale from Xilinx. They now have a Parallel cable IV which was not suitable for the

reasons above.

The Parallel Cable III satisfied all of the above criteria. Serck is still able to purchase these cables

from Xilinx and at a low cost. The cable passes the signals virtually straight through with no

complex protocols being used within the cable, in this respect it was the “dumb” cable I was after.

The cable also contains a buffer that will protect my PC’s parallel port.

Figure 6 Parallel Cable III



Figure 7 Cable Schematic

The limitation with the current cable setup is the boards I can connect to. Because the PC Parallel

port outputs are 5V I am not able to connect to Serck Controls many 3V boards. This limitation is

from the 74HC125 chip. Using this cable would most likely damage the board I connect to.

However I have found an alternative chip from Fairchild. The 74LCX125 Low Voltage Quad

Buffer with 5V Tolerant Inputs and Outputs. The LCX125 inputs tolerate voltages up to 7V

and hence allow the interface of a 5V system to 3V systems. This makes the 74LCX125 perfect

for what I need. This modification will be needed before I connect to any of Serck Controls 3V

circuit boards, such as the 586 eNET.



7.1.2 Final Cable Used

My project will be demonstrated using the Digilab XC2 circuit board. Described in section 7.3 in

more detail, this circuit board was the only way of writing a working boundary scan test program

that incorporates demonstration modifications. One of the benefits of this board was it had a

DB25 female socket which allowed me to use the common parallel cable used to connect your

printer to your PC.

The board incorporates a 3.3V buffer IC with 5V tolerant inputs (coincidently the same chip I

chose to modify the Parallel cable III with) and thus offered the same level of protection for my

PC.

7.2 The Parallel Port

The Parallel port is a 25 pin female connector at the back of almost all PC’s. It is commonly used

for connecting printers and hence is often known as the Printer Port.

The pins of the DB25 connector are divided in to three registers, they are:

1) Data Register (data bus)

2) Control Register

3) Status Register

The addresses of the three registers on my PC are:

Data Register = &H378

Status Register = &H379

Control Register = &H37A



Figure 8 Parallel Port

7.2.1 Pin Assignments

The Parallel Cable III uses the following pin assignments

Signal Pin Register/bit

TCK 3 Data / 1

TDO 13 Status / 4

TDI 2 Data / 0

TMS 4 Data / 2

Prog 6 Data / 4 Table 1 Parallel Cable III pin assignments

When I initially started testing the Parallel Cable III with my code, I found I never received any

high signal on the TDO line. This was because I initially did not have the Prog signal high. As

shown in the cable schematic, Figure 7 Cable Schematic, this signal is necessary to ensure the

signal is not pulled to ground. When the “prog” signal is LOW, U1 is on and therefore will tie the

output to ground. Having the “prog” signal High allows the output to be correctly received.

7.3 Circuit Boards

In the beginning I was interfacing with Serck Controls 386 eNET circuit board. This board

however had only one JTAG compatible component and was therefore not suitable for my

project. I was then given one of the latest 586 eNET circuit boards. This had three JTAG

compatible components but was still not ideal. Due to the complexity of the hardware it was not

suitable for a prototype tester.



The 586 eNET had a small selection of interconnections between these devices but these were via

a buffer meaning although it was possible to still simulate it was not ideal. Modifying the board

for demonstration was also something that was not necessarily possible. The other major problem

was the expense to replace this board. It was possible for me to damage the board if I made any

mistakes and as a result it was decided after discussions with myself and the Serck Controls

Hardware engineers that it would be best to use another board.

Serck Controls have recently designed the Magna product and there were several prototype

boards I experimented with but all had there own issues. Finally the Digilab XC2 board was

discovered.

7.4 Digilab XC2

The Digilab XC2 board that I obtained was ideal. The board provides a basic digital system built

around Xilinx CoolRunner 2 series. Some of the features include:

• Built in JTAG programming circuit

• Power Supplies

• On-board prototype area

• Pads for a second CoolRunner 2 in a VQ44 package

• Flexible routing of JTAG programming signals between the CPLDs

• Full routing of all I/O signals from both CPLDs to expansion connectors and/or

breadboard area

The board as I received it contained a CoolRunner-II XC2C256 TQ144 CPLD. I immediately

ordered the optional CoolRunner-II XC2C64 VQ44 CPLD. I now had 2 JTAG compatible

devices in my chain and was able to design my test/demonstration board.

Following are 3 images from the Digilab XC2 Reference Manual [3] that describes the layout of

this board:



Figure 9 XC2 Block Diagram

Figure 10 Parallel port connectors and signals



Figure 11 Signal routing to expansion connectors

For my demonstration I wanted to be able to run my JTAG Hardware Debugger with a board with

or without faults. This would allow me to demonstrate my program successfully detecting faults.

I decided to design some circuitry that enabled me to simulate an Open circuit and also simulate a

short between two parallel tracks. I have done this with two 8 switch dip switches.



Figure 12 Modified Digilab XC2 Board

As can be seen from this digital photograph there have been some obvious modifications. I have

highlighted some of the major components of my demonstration board. Below describes each

part:

1. This is a common eight switch dip switch. Only the 1st and 2nd switches are connected.

Turning switch 1 on will short net 6 and 7 together. Switch 2 will short nets 8 and 9.

2. This is the 32 pin flash socket that holds the AM29LF040 flash chip. A very similar

socket is used on the eNET RTU’s produced by Serck Control

3. This eight switch dip switch has switches 1 to 5 wired in to my circuit. Turning any of

these switches off will simulate an open circuit in the corresponding net. i.e. Turning

switch 1 off will cause an open circuit for net 1.

1

2

3

4 5

6 7



4. This is the additional microchip I ordered from Xilinx. It is a XC2C64 VQ44 CPLD.

5. This is the XC2C256 TQ144 CPLD that came with the board.

6. 5V DC connector

7. DB 25 Parallel Port Connector

My design has 5 parallel nets, connected from one CPLD pin to another, all wired via a DIP

switch (labeled item 3 above). This enables me to break the connection to demonstrate an open

circuit. I also wired another 4 nets between my two CPLDs. Between the first two nets I wired in

the first switch on the 8 switch dip switch, and in between the last two I wired in the second

switch. This allows me to simulate shorts between tracks.

Figure 13 Demonstration Circuit



The table below shows the relationship between the expansion locations in the above diagram and

the CPLD pins. As my code access all pins via its corresponding Boundary scan cell I have

detailed the CPLD pin and boundary scan cell. Also shown in the table are the Net labels I used to

describe each demonstration interconnect.

Table 2 Board Pin out assignments

CPLD: xc2c64

Board Pinout

BSDL input Cell Net

C4 74 C5 77 6 C6 80 C7 83

7

C8 92 C9 95 8 C10 191 C11 188 9 C12 185 1 C13 167 2 C14 164 3 C15 161 4 C16 158 5

All up I wired in 9 interconnections or ‘Nets’ that I test for my demonstration. I have soldered

extra circuitry so I can simulate opens and shorts and have included resistors throughout my

design. The resistors are all 1K� and these are to ensure I did not damage any of my hardware

during my initial stages. Each pin on the CPLD can be configured to be an output or an input

based on the vector I shift into the device. During my testing and development phases I was

concerned that I may make a mistake and accidentally try to drive two outputs that were

connected via my additional circuitry, or something similar. The resistors were added in to

minimize damage to any components in the event of a coding error.

After successfully modifying the board to include the switches and additional circuitry I am able

to demonstrate exactly the faults my code looks for. In addition to what is already described, a 32

pin flash memory socket was also added to the board. This is the same as what is currently used

on Serck Controls eNET RTU’s. Although the flash memory is not a JTAG compatible chip it is

possible to indirectly test for faults. I have access to the address and data lines as they are

CPLD: xc2c256 Board Pinout

BSDL input cell Net

D12 119 1 D13 122 2 D14 125 3 D15 131 4 D16 134 5



connected to the CPLD. It was therefore theoretically possible for me to use my JTAG interface

to read and write from memory. This is described in more detail in section 7.5

7.5 Flash Memory Socket

Both the 586 eNET and the 386 eNET have a 32 pin socket to hold the 512kb Flash Memory.

This is necessary because the ROM needs to be programmed (and sometimes reprogrammed, eg.

update to system firmware) after production of the board. At the moment a technician would

program the flash memory in a separate piece of hardware connected to a PC. The programmed

chip is then inserted on the board via this socket.

For this reason the socket has been necessary however having a socket present on the circuit

board introduces a weak point in the design as sockets like this are vulnerable to a variety of

problems.

Board mounted sockets can introduce faults caused by rough handling by technicians as they

remove and replace the chip when programming. The damage caused could by electrostatic, bent

pins or damage caused by foreign objects such as dirt or other materials being introduced as the

protective cover must be removed to access these sockets. Serck have found that in some

instances after a period of time, (approx 5-10yrs), these sockets have become unreliable often

from contact degradation or damage from years of rough handling.

A physical advantage is the socket itself is considerable larger than the chip dimensions so

removing this socket will create some more space on the circuit board. Another advantage is in

the use of ‘Conformal Coating’. This is a protective coating that can be sprayed onto the circuit

board. This provides environmental protection, from things such as humidity and moisture. A

socket cannot be sprayed as it would cover the contacts and hence cannot have this protection

applied.

My Final Year project has showed that it is possible to program this flash memory via the

existing JTAG interface. This is a considerable achievement as it means the socket is no longer

necessary and eliminates the vulnerabilities described above. This ‘breakthrough’ is something

that will be incorporated by the Serck Controls Hardware team in the next designs of the eNET



circuit board. At this stage it is very likely that the current 32 pin socket will be removed from all

future designs.

7.6 Serck Controls Circuit Boards

Serck Controls Design and Test there own custom Circuit boards. Described below are two of

their RTU products, the 386 and 586 eNET. The eNET series is the newest range of Serck

Controls Remote Telemetry Units. The major difference between the 386 and the 586 eNET is the

type of processor used.

Figure 14 Serck Controls eNET RTU

7.6.1 386 eNET

The 386 eNET is state of the art and has many advanced features. [4]Features include:

• Supports protocols such as DNP3, Modbus master and slave

• IEC61131-3

• Ethernet Port



• 5 Communication Ports

• I/O count of up to 32 Digital Inputs, 16 Relay Outputs, 12 Analogue Inputs and 4

Analogue Outputs

• Remote Diagnostics, configuration, programming and debugging.

7.6.2 586 eNET

The 586 is the next generation eNET. Pictured above, features include all of the 386 eNET

capabilities plus these additional features:

• Standalone SCADA Server with OPC, mimic and trend support (SCXe)

• Full operational access via web (SCXe)

• Two 100Mbps Ethernet ports

• Two Compact Flash ports

(SCXe is a software platform developed by Serck Controls that can be hosted on the 586 eNET

allowing for full SCADA functionality locally within the RTU)



8 Software

8.1 Code Language

All software was coded in Visual Basic (VB). VB is a programming system from the Microsoft

Corporation for Microsoft Windows. VB is ideal for making windows based applications. The

choice to write my software using VB rather than other coding languages such as C was a

personal choice I made as I have used this language previously and found it very user friendly.

For my application VB is more than sufficient and offered all the necessary tools I needed.

8.2 Interfacing with the Parallel Port

Interfacing with the parallel port is more difficult now than it was in previous years. Previously,

before Microsoft Windows was around you could directly access I/O ports and nearly every

language supported a special command for doing so. As Windows emerged things changed but it

was still possible to access I/O operations at the application level. Most languages did not support

a direct method but with a small piece of assembly language this kind of low level control was

possible.

Windows NT/2000/XP was designed to be the ‘secure’ operating system and did not permit port

I/O operations at the application level at all. This meant that a program with IN and OUT

assembly instructions that ran perfectly under Windows 98 will not run under Windows XP.

Windows NT/2000/XP does, however, allow I/O instructions in its kernel mode drivers. So

instead of trying to write my own, or re-write what has already been done I did a search to see

what I could find to achieve my basic functions.

What I found was Inpout32.dll for Windows NT/2000/XP. The DLL (dynamic link library) has

many features such as:

• Uses a kernel mode driver embedded in the DLL

• No special software or driver installation is required

• No special API’s are required, there are only two functions Inp32 and Out32

• Can be easily used with Visual Basic.



This was exactly what I wanted and worked perfectly. My code therefore utilises these two

functions provided by this DLL.

8.3 Software Design & Implementation

There were many challenges and difficulties when it came to writing my software. As described

above I had a method to write to the parallel port of my PC but everything else had to be

constructed from scratch.

My software relied heavily on interfacing to the boundary scan components on my board. To

achieve this, there was some essential information that I needed. Information needed included:

• Instruction register length

• Instruction opcodes

• Contents of the ID register

• Boundary scan length

• Boundary scan cell assignments

This information was essential and without it I could not have achieved anything. For example

when selecting the instruction register for each device the length of the boundary scan path

reduced to the accumulated length of each instruction register in my chain. These were often only

4 or 8 bits in length each. If I then chose the boundary scan register the length would change to a

combined length of several hundred bits in length. It was essential I knew not only exactly how

long this path was but the exact location of each boundary scan cell I was concerned with.

This was extremely difficult and near impossible to debug. If things did not perform as expected

it was very hard to know if I had for example, shifted one too many times or even one too little.

All the above information however is available for each component that is boundary scan

compatible.

This information is available in what is called ‘BSDL files’, and these proved at times to be my

greatest tool. Each boundary scan compatible component has a corresponding BSDL file. As

described in [5], BSDL is a standard data format that describes the implementation of JTAG in a

device. The purpose of BSDL is to provide a common language to describe boundary scan



implementations in different devices from multiple vendors. Vendors of components supporting

the IEEE 1149.1 standard are expected to supply BSDL descriptions to customers. It is these

BSDL files that I used to determine the bit sequence required when performing my tests

The general layout of my code is described below. It is important to relies that each component in

itself might require hundreds or even thousands of clock cycles.

1. Load Instruction register of each component with Device ID opcode

2. Shift out the resulting ID codes of each device in the JTAG chain

3. Load EXTEST opcode into instruction register of each device

4. Load test vector 1

5. Shift vector out and store this result

6. Repeat 4 & 5 until all 8 vectors have been loaded and results stored

7. Analyse results from all vectors and determine faults and locations

(My ‘Memory Interface test’ which is an additional test has a very similar structure to that

described above)

8.4 Testing structure

My JTAG Hardware Debugger has been designed to not only detect faults but identify the type

and location. This information is presented as a text document report that can be saved or printed

for reference as well as immediate feedback from the software that allows the operator to know

whether a fault has been detected. All specific information is included as part of the report.

I have split my testing structure into 3 distinct parts.

Part 1 will be to interrogate the board and determine the chip ID’s of all devices on the JTAG

chain. The chip ID contains the Manufacturers ID, Part Number, and Version. This initial part

will determine if the right components have been mounted to the board and in the correct

orientation.



This part of the test will also confirm the JTAG chain is unbroken. This infrastructure test is

essential because the execution of the other parts of my testing requires the boundary-scan

infrastructure on the board to be correct.

Part 2 of my testing is the most complex. To accurately test all interconnections between these

devices requires multiple combinations of high and low signals. This is necessary to be able to

determine if firstly, a fault exists, and secondary, what type of fault exists.

Simply sending all 1s and then sending all 0s is not sufficient to accurately find faults. The

CoolRunner series of CPLDs have weak pull-ups on all the inputs. This means unless they are

driven low the value will be logic 1. Put slightly differently if an input is only receiving 1’s

although a combinations of 1’s and 0’s are being sent then it is a good chance there is an open

circuit. For this reason detecting open circuits is relatively straight forward, detecting shorts is

more difficult.

Figure 15 Interconnect Test Example (a)

Consider the situation above, assume both devices are IEEE 1149.1 compliant and the left hand

device drives values into the right hand device. There are three parallel lines and we suspect a

short between the top and middle interconnects. Sending a vector of 111 would result in a vector

of 111 being received. This result would suggest that there are no faults, similarly if we sent 000

we would receive 000, again suggesting there are no faults. The problem is a short behaves as a

logical OR gate. Therefore it is only by sending a pattern such as 101 that we would observe a

fault as indicated in the figure below.



Figure 16 Interconnect Test Example (b)

The number of parallel interconnects will effect how many combinations are needed. In the above

situation it is still not clear from the results yet whether the middle interconnect is shorted with

the top or bottom interconnect, or even if it is a short or an open! So as can be seen detecting

short circuits (or open circuits) is a little more complicated than what might be first assumed.

For my demonstration board, the largest collection of parallel interconnects is 5, as a result my

testing involves 8 different vector combinations to be able to determine a fault and identify

exactly which lines are involved.

Exactly what combinations are needed is a question in which I went researching for an answer.

The question was answered in 1974 in connection with a similar requirement for testing ribbon

cables. [6] Kautz showed that a sufficient condition to detect any pair of short-circuited nets was

that the combination of 1’s and 0’s must be unique for each net. This was however not sufficient

as can be seen from the figure below.

Figure 17 Interconnect Test Example (c)



As shown above it now suggests that the short may exist between all three nets. To avoid this

discrepancy I also send a ‘walking 1’ across the nets. As illustrated below I can now see that there

exists no fault on the bottom net and the top and middle nets are shorted together.

Figure 18 Interconnect Test Example (d)

So for my testing my program performs 8 phases. Each phase tests one vector combination and

when all phases are complete I then analyse the results. The number of phases, or vectors needed

depends on the number of parallel interconnects (or nets).

Part 3 is analysing the results. When it comes to detecting faults and determining what fault

exists I first compare the pattern I sent with the pattern I received. If the patterns are identical I

know that no fault exists on this net. If I do detect a fault I need to then distinguish whether it is a

short circuit, an open circuit or an unknown fault. My code first determines whether it is an open

circuit by looking at the pattern received. If the pattern is all 1’s then I mark the fault as an open

circuit. Otherwise my code compares the pattern to the patterns received from the adjacent nets. If

these adjacent nets are identical I then mark the nets as a possible short.

8.5 Flash Memory Test

In addition to the above software testing that identifies possible ‘opens’ and ‘shorts’ in

connections between JTAG compatible devices I have also created an additional test. This test I

have labeled the ‘Memory Interface test’. Although the Flash memory currently used on the Serck

Controls hardware is not JTAG compatible I can still indirectly test the Data and Address lines. I

have access to all the Data and Address lines as these have been connected to my CPLD.



Writing data to memory and reading it back, although not as comprehensive, can test for faults in

these lines. I have therefore included as part of my JTAG Hardware Debugger code, to write and

read different data to different memory addresses. This adds an extra dimension and makes the

test a lot more comprehensive. In total there are 19 address lines and 8 data lines.

The diagram below describes the configuration of the flash memory on my Digilab board. This

configuration is very similar in theory to what is setup on the eNET RTU’s. I have access to the

address and data lines and so in theory can program the flash memory. It is by writing data to a

combination of memory addresses and then reading this data back that I am able to confirm these

data and address lines have no faults.

Figure 19 Flash Memory address and data lines

The fact that it is possible to write to the flash memory via the existing JTAG port of the circuit

board have follow on consequences for the Serck design team. This has several benefits described

in section 7.5



9 Results

For my Final Year Project I set out to create a Hardware Debugger that can detect faults on a

circuit board. This project was suggested by Serck Controls my industry sponsor, and my current

employer.

There were many challenges through the life of this project but I am proud to have a working

Hardware Debugger. My program can detect faults, identify where they exist and suggest the

possible cause.

Figure 20 Windows Interface

Before executing my program the operator is required to enter their name or identification

number. This is used in the report that states the time and date the operator executed the test as

well as the results.

The test begins by displaying the ID of all devices on the chain, this is displayed for the operator

to check. This confirms the correct components are installed and in the correct locations. After



this the program finishes and the operator is immediately notified whether the board passed or

failed the boundary scan test. Details of any faults are located within the report. My program

finishes by asking the operator to enter a name for the report. The report is then saved with this as

the filename.

In addition to the boundary scan test the operator has the option to enable the Memory Interface

test via a simple ‘tick box’. Selecting this option will include these results in the report.

The following page shows a sample report produced.



******************************************************************** * 2005 Newcastle University Major Project * * * * JTAG Hardware Debugger * * Boundary Scan Test Report: * ******************************************************************** Date: 9/28/2005 1:34:35 PM Operator: Matthew Youd **** Devices on JTAG Chain **** Chip 1 details: Manufacturer ID 00001001001 Part Number 0110110001011110 Version 0000 Chip 2 details: Manufacturer ID 00001001001 Part Number 0110110101001100 Version 0000 Chip 3 details: **** No more chips on the Chain **** **** Execute Boundary Scan Test **** Execute phase 1 Execute phase 2 Execute phase 3 Execute phase 4 Execute phase 5 Execute phase 6 Execute phase 7 Execute phase 8 **** Analyzing Results **** Test Complete There were no errors **** Execute Flash Memory Test **** Flash memory test 0 PASS Flash memory test 1 PASS Flash memory test 2 PASS



10 Conclusion

My Final Year project has been a success as I have achieved all aims. I have a working hardware

debugger that uses the IEEE 1149.1-2001 “Test Access Port and Boundary-Scan Architecture”

and not only does it detect faults it also identifies the location and possible type of fault. In

addition to this I have created a test that will test the address and data lines to memory by a

combination of reading and writing data to memory locations.

Serck Controls my industry sponsor have been most interested in the latter as it creates an

opportunity to eliminate having a 32pin socket on their RTU boards. As discussed in this report,

this has several benefits. A possible extension to this project would be to utilise what I have

proven possible and create a programmer that programs memory all through the JTAG port.

I am very satisfied and proud of what I have achieved and I think Serck Controls is equally

satisfied after sponsoring me for this project.



11 Bibliography

[1] Boundary-Scan Tutorial, 2000. Retrieved: May 2005, from http://www.asset-

intertech.com

[2] John Chubb, SPEA, 1999, “Flying Probers Circumvent Loss of Test Access”.

Test & Measurement World Online webzine. Retrieved May, 2005 from http://www.reed-

electronics.com/tmworld/

[3] Digilab XC2 Reference Manual Revision: October 26, 2002. Retrieved from

www.digilentinc.com

[4] PDS eNET Series Programmable RTU, 2005. Retrieved May, 2005 from

http://www.serck-controls.com.au.

[5] Actel, BSDL Files Format Description November 2002

[6] W.H. Kautz, "Testing of Faults in Wiring Interconnects," IEEE Trans. Computers,

Documents

Student: Matthew Youd c2005240 Project: J T AG Hardware Debugger