Software Techniques

8.12 Freeing One Hardware Stack Location

There are certain cases where a section of code should use DO looping, but it is not clear whether the HWS is full or not. An example is an ISR, which may be called when two nested DO loops are in progress. In these cases it may be desirable to free a single location on the HWS for use by a section of code such as an ISR. The following code shows how to free one location for an ISR:

;Interrupt Service Routine - Frees Up One HWS Location

;14 extra Icyc, 12 extra words

;

ISR

;(instructions) DO #3,LABEL INCW A

LABEL

;(instructions)

For ISRs that are maskable, it is better to follow the recommendations outlined in Section 8.6.4, “Nested Loops,” to reduce the overhead needed for freeing up one HWS location. This greatly simplifies the setup code required when entering and exiting the ISR.

8.13 Multitasking and the Hardware Stack

For multitasking, it is important to be able to save and later restore the hardware DO loop stack (HWS). This section shows code that will perform the save and restore operations. When reading the HWS, two locations of the stack are read as well as the current state of the HWS, contained in the NL and LF bits of the OMR and SR, respectively. Each read of the HWS register pops the HWS one value, and each write of the HWS register pushes the HWS one value.

Multitasking and the Hardware Stack

8.13.1 Saving the Hardware Stack

An example of reading the entire contents of the HWS to X memory is shown in the following code:

;Save HWS

;4 Icyc, 4 words

;save in X memory

8.13.2Restoring the Hardware Stack

When restoring the HWS, it is first necessary that the HWS be empty. If this is unclear, performing two reads from the HWS will ensure that the stack is empty. Once this is true, then the HWS can be restored. An example of restoring the contents of the HWS from X data memory follows:

;Restore HWS, 10 words, 14 Icyc worst case

;Assumes R2 points to “stored” HWS

;Destroys R2 register

OVER

Software Techniques

Chapter 9

JTAG and On-Chip Emulation (OnCE™ )

The DSP56800 family includes extensive integrated test and debug support. Two modules, the On-Chip Emulation (OnCE) module and the test access port (TAP, commonly called the JTAG port) provide boardand chip-level testing and software debugging capability. Both are accessed through a common JTAG/OnCE interface. Using these modules allows the user to insert the DSP chip into a target system while retaining debug control. This capability is especially important for devices without an external bus, since it eliminates the need for a costly cable to bring out the footprint of the chip, as required by a traditional emulator system.

The OnCE port is a Motorola-designed module used to debug application software used with the chip. The port is a separate on-chip block that allows non-intrusive interaction with the DSP and is accessible through the pins of the JTAG interface. The OnCE port makes it possible to examine contents of registers, memory, or on-chip peripherals in a special debug environment. No user-accessible resources need be sacrificed to perform debugging operations.

The JTAG port conforms to the IEEE Standard Test Access Port and Boundary-Scan Architecture specification (IEEE 1149.1a-1993) as defined by the Joint Test Action Group (JTAG). The JTAG module uses a boundary scan technique to test the interconnections between integrated circuits after they are assembled onto a printed circuit board. Using a boundary scan allows a tester to observe and control signal levels at each component pin through a special register coupled to each pin, called a boundary scan cell. This is important for testing continuity and determining if pins are stuck at a one or zero level.

This chapter presents an overview of the capabilities of the JTAG and OnCE modules. Since their operation is highly dependent upon the architecture of a specific DSP56800 device, the exact implementation is necessarily device dependant. For more complete information on interfacing, the debug and test commands available, and other implementation details, consult the appropriate device’s user’s manual.

9.1 Combined JTAG and OnCE Interface

The JTAG and OnCE modules are tightly coupled. The JTAG port provides the interface for both modules and handles communications with host development and test systems. Figure 9-1 on page 9-2 shows a block diagram of the JTAG/OnCE modules and external host interface.