ZSP FlashInitialization
Flash memory programming through boundary scan

Introduction

Requirements

Procedure

Known Problems

Theory and Capabilities

Sample command files

ZSP400 DSP core features both hardware and software modes of emulation.

• In hardware mode emulation, the ZSP's internal registers are retrieved and updated using serial scans by way of the device's JTAG scan path; multiple internal registers are scanned in/out of the device in a single scan sequence.
• In software mode emulation, access to the ZSP internal registers is accomplished by way of an on-chip, JTAG-accessible mail box and special software monitor interrupt service routines installed in the target ZSP application board's external Flash program memory.

For normal debugging, generally the software mode of emulation is used. Prior to use, the software monitor interrupt routines must be installed in the external Flash Program Memory.

Back to Top

As such, this creates the seemingly paradoxical chicken-and-egg problem of having to install the appropriate software interrupt service routines in the target ZSP application board's external Flash program memory before the ZSP-USB-JTAG can be used for debugging

Fortunately, the ZView debugger has the ability to create and execute custom JTAG boundary scan command files; this allows initialization of the ZSP's external Flash program memory to support software emulation mode.

The following text explains the procedures necessary to initialize the target ZSP's external Flash program memory with the required software mode emulation interrupt routines for the monitor prior to using an emulator for software mode debugging.

Software mode emulation for the ZSP400 device requires special monitor code to be executed on the target device. The monitor program enables the high speed data exchange through the target ZSP device JTAG port. One way of providing this code to the ZSP core for execution is by loading the monitor routines into the target ZSP's external flash ROM, or, alternatively, external RAM, before releasing a DSP reset.

For new systems in production that are assembled with an external Flash memory, the easiest way to initialize the monitor code image is by way of a command file that performs a series of JTAG boundary scan sequences for a specific manufacturer's Flash memory device. Another method is to simply install a pre-programmed (or socketed) Flash memory device; however, requiring such a device creates problems with software updates. Also, users can bootstrap through the host port and load a program to initialize the monitor code.

The JTAG boundary scan programming procedure is the slower method, but advantageously can be executed on the assembled system without any code being executed on the target processor.

Back to Top

Programming the external Flash program memory is accomplished by placing the target ZSP device in the JTAG EXTEST mode. Internal logic is disconnected from the device's pins. All signals are written/read by way of serially shifting data to all the logic cells that control the state of the package pins through the JTAG TAP controller of the JTAG scan chain connected devices.

Different flash memory manufacturer programming procedures are supported, including options for user definition of the Flash programming algorithm. The ZSP-USB-JTAG emulator programming speeds are as follows:

• For AMD type flash memory the speed is about 20 words per second.
• For Micron type flash memory,which requires only 2 writes (instead of 4 as is the case for an AMD device), the programming rate is about 40 words per second.
• For a typical monitor size of 2K words, this programming speed will require about 50 seconds for Micron flash initialization, and about 100 seconds for the AMD device.

BSDL file for ZSP device

Boundary Scan Description Language file provides standard description of the JTAG's boundary scan cell's configuration. This file is provided by the device manufacturer.

JTAG controller

Physical device providing interface between host computer and target board circuitry. In this application note, ZSP-USB-JTAG is used as an example.

Programming application

This is the software executed on the host computer for transferring the image into the flash memory device. For this application note, the command line interface of ZView.exe is used as a tool to create custom command files which can then be executed to accomplish the Flash programming function. The described are fully supported and tested with current version fo the ZView.exe debugger.

Flash image data

This is the binary or text file containing the flash image to be read by the host application and programmed into the target ZSP's external Flash program memory.

leddt402eb.bvc

Command file initializing EXTEST operation, and assigning pins to LED control functions of the DT402EB board with led control loop through the boundary scan

flashdt402eb.bvc

Command file executing all functions needed for the flash reprogramming on DT402EB

flashinitdt402eb.bvc

Command file to initialize boundary scan parameters for flash access on the DT402EB - flashdisplay, flashload, flashclear

lsi402zx.bsdl

BDSL file for ZSP402ZX

ledeb403.bvc

Command file initializing EXTEST operation, and assigning pins to LED control functions of the EB403 board with led control loop through the boundary scan. LEDs are controlled by access of peripheral memory location D:0xFF00.

flasheb403.bvc

Command file executing all functions needed for the flash reprogramming on EB403, this is provided for reference only, programming was tested only fro flash address above 0x10000

flashiniteb403.bvc

Command file to initialize parameters for boundary comamnds for EB403 - flashdisplay, flashload, flashclear

lsi403lp.bsdl

BDSL file for ZSP403LP

bmreadid.bvc

Command file executing functions to read back the Flash Manufacturer ID value in the "Micron" access mode

bmreadid3.bvc

Command file executing functions to read back the Flash Manufacturer ID value in the "AMD" access mode

DT402EB -April 2006

When a halt request is issued through the JTAG port, the HWFLAG register is getting corrupted. This is related to the ZSP 402ZX JTAG feature extending Update-DR for the whole TCK period. This problem is not seen with TCK rates above 1 MHz, so both the ZSP-USB-JTAG and the DT402EB integrated emulator will experience this problem. During the halt request, a value of 0x6000 is written into the DEI register, which overwrites the stored value. The fix adds 12 NOPs before the HWFLAG register is stored into the DEI. To modify the DT402EB flash ROM, download the appropriate board revision files and execute it:

EB403

Unable to program Flash ROM below 0x10000. This could be due to the FPGA decoding. This will require further investigation.