Search NASA⌕ Search

SEARCH · Search NASA

Results for “JTAG”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

7 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS1998

Use of SX Series Devices and IEEE 1149.1 JTAG Circuitry

This report summarizes the use of SX series devices and their JTAG 1149.1 circuitry. 'JTAG' circuitry was originally designed to standardize testing of boards via a simple control port interface electrically without having to use devices such as a bed of nails tester. JTAG is also used for other functions such as executing built-in-test sequences, identifying devices, or, through custom instructions, other functions designed in by the chip designer. The JTAG circuitry is designed for test only; it has no functional use in the integrated circuit during normal operations. The JTAG circuitry and the mode of the device is controlled by a circuit block known as the 'TAP controller,' which is a sixteen-state state machine along with various registers. The controller is normally in an operational state known as TEST-LOGIC-RESET. In this state, the device is held in a fully functional, operating mode. However, a Single Event Upset (SEU) may remove the TAP controller from this state, causing a loss of control of the integrated circuit, unless certain precautions are taken, such as grounding the optional JTAG TRST signal.

Katz, Richard B.↗
NASA NTRS1998

Use of SX Series Devices and IEEE 1149.1 JTAG Circuitry

This report summarizes the use of SX series devices and their JTAG 1149.1 circuitry. 'JTAG' circuitry was originally designed to standardize testing of boards via a simple control port interface electrically without having to use devices such as a bed of nails tester. JTAG is also used for other functions such as executing built-in-test sequences, identifying devices, or, through custom instructions, other functions designed in by the chip designer. The JTAG circuitry is designed for test only; it has no functional use in the integrated circuit during normal operations. The JTAG circuitry and the mode of the device is controlled by a circuit block known as the 'TAP controller,' which is a sixteen-state state machine along with various registers. The controller is normally in an operational state known as TEST-LOGIC-RESET. In this state, the device is held in a fully functional, operational mode. However, a Single Event Upset (SEU) may remove the TAP controller from this state, causing a loss of control of the integrated circuit, unless certain precautions are taken, such as grounding the optional JTAG TRST signal.

Katz, Richard B.↗
NASA NTRS2005

Preliminary low temperature tests of a digital signal processor

This paper describes an initial experiment performed to assess the electrical behavior of the Innovative Integration board containing a Digital Signal Processor (DSP) with its JTAG (Blackhawk) connector at low temperatures. The objective of the experiment is to determine the lowest temperature at which the DSP can operate. The DSP was tested at various low-temperatures and a Genetic Algorithm was used as the DSP test program.

temperatures↗
NASA NTRS2000

Programmable Logic Application Notes

This column will be provided each quarter as a source for reliability, radiation results, NASA capabilities, and other information on programmable logic devices and related applications. This quarter will continue a series of notes concentrating on analysis techniques with this issue's section discussing: Digital Timing Analysis Tools and Techniques. Articles in this issue include: SX and SX-A Series Devices Power Sequencing; JTAG and SXISX-AISX-S Series Devices; Analysis Techniques (i.e., notes on digital timing analysis tools and techniques); Status of the Radiation Hard reconfigurable Field Programmable Gate Array Program, Input Transition Times; Apollo Guidance Computer Logic Study; RT54SX32S Prototype Data Sets; A54SX32A - 0.22 micron/UMC Test Results; Ramtron FM1608 FRAM; and Analysis of VHDL Code and Synthesizer Output.

Katz, Richard↗
NASA NTRS2003

Increasing software testability with standard access and control interfaces

Testing is the most common method of determining whether a software system satisfies its requirements. Traditionally, testing starts with the detailed examination of individual functions or methods, progresses through the integration of functions or methods into subsystems, and ends with testing the functionality and behavior of the completely integrated system. At each stage of testing, the amount of functionality and behavior of the artifact being tested is increasingly limited. One reason for this is that it becomes impossible to test all paths through the system within a reasonable amount of time. However, another reason for this progressive decrease of test coverage has to do with increasingly limited control of and visibility into the state of the artifact being tested. During unit test, it is rather simple to control the inputs of individual functions or methods or view their internal state - modem development environments provide adequate facilities for doing so. However, these facilities do not scale up to the testing of partially or completely integrated systems. Control of and visibility into the system's state is then limited to the input and output facilities provided by the software itself as well as the hardware on which the software is hosted during the test. These facilities are usually insufficient to precisely control the state of individual components or sets of components of the system; they are also inadequate to the task of displaying on demand the state of specific components. We describe an approach to improving the testability of complex software systems with software constructs modeled after the hardware JTAG bus, used to provide visibility and controllability in testing digital circuits.

Tamir, Yuval↗
DOE OSTI2023

Towards generic memory forensic framework for programmable logic controllers

A Programmable Logic Controller (PLC) is a microprocessor-based controller that is used to automate physical processes in critical infrastructure and various other industries and manufacturing sectors. Initially, PLCs were completely isolated from the Internet, and cyber security was not incorporated at the time of development. The introduction of industry 4.0 and the evolution of ICS systems to communicate over public IP addresses from the Internet enhanced productivity and efficiency, but Internet connectivity exposed the systems and their vulnerabilities, which led to an increase in cyber attacks. When a system is sabotaged/compromised, security analysts need to get to the root cause of the attack as quickly as possible to recover the system. To do so, memory forensic analysis is critical to provide a unique insight into the run-time memory activities and extract a reliable source of evidence. In this paper, we analyze the memory structure of the Schneider Electric Modicon M221 PLC. To build a memory profile, we reverse engineer the communication protocol and conduct differential analysis to gain knowledge about the structure of the memory and the low-level representation of control logic instructions. We then identify dynamic and static memory regions by modifying different project fields and conducting differential analysis, which allows us to identify boundaries of critical memory structures and extract important forensic artifacts that can be found in the memory. The Python implementation of the memory profile can help reduce the time and effort required for manual analysis in case of cyber incident or system failure.

97 MATHEMATICS AND COMPUTING↗