Using ChipView with PromICE

1994 Grammar Engine Inc.
Version 2.0a
September 1994


Grammar Engine, Inc.
921 Eastwind Drive 
Suite 122 
Westerville OH 43081
(614) 899-7878


This document will detail how the ChipView-51 debugger works with the 
PromICE ROM emulator from Grammar Engine Inc.  This document is intended
to help you understand the debugging concept as it applys to the 80x51
series processors.

The ROM Monitor generally is configured and installed in the target system's 
ROMs and communicates with the ChipView-51 debugger front end running in 
the host system via a serial port or some other communication scheme.  
When the PromICE is being used to emulate the target system's ROMs, a PromICE 
unit equipped with the AI option can be used to communicate with the debugger
front end via the PromICE serial port.  The AI option adds a virtual 
serial channel to the PromICE, accessible through the ROM socket.  This 
channel is called ROMart.  This channel operates on read cycles alone and
this allows target independent I/O through the ROM socket.  This way the 
host communicates with the target system through the same port through 
which it is communicating with the PromICE.  This allows support for 
those targets that have no spare I/O available for communicating with the 
debugger.  The PromICE allows development of code in the ROM space, 
instead of down-loading and debugging in RAM.  Great time savings can be 
achieved by not having to develop a custom board support package (BSP) 
for your target.  The PromICE is plugged into the ROM socket and there 
is no direct connection from the host to the target. 


The same port that is used to install the Debugger Monitor in the ROM 
(by down-loading it to the PromICE) is used to communicate with the 
monitor via the AI option (ROMart).  User applications can be down-loaded 
into ROM (connect 'write' line to the PromICE).


ChipView-51 Requirements:

ChipView requires certain hardware modifications to take full advantage of all
of its features.  Following is a list of target requirements and why
you may need them:  Overlapping CODE/XDATA space:  If you don't have
the ability to overlap the space you will NOT be able to download your
application through the debugger, single step or set breakpoints in your
code.  How you go about this overlap is up to you, but you must tell the
monitor how to overlap the memory space and/or where the overlap is.

One target interrupt:  This allows you to bring control back from a "runaway"
application.  For example:  If you press the F9 function key the debugger
jumps to the application and lets it run at full speed.  When you press
the F9 key again, the interrupt is asserted and control comes back to the
monitor.

If you want to overlap the CODE/XDATA space you will need to 
modify your target hardware.  How you do this is up to you, but you will 
need to configure the monitor to take advantage of the modifications.


8x51 Debugging Concept:  

The 8051 has separate read lines for RAM and ROM and a write line for the RAM.  
This makes it impossible to do a write cycle to the ROM space without modifying 
the target system.  In order for ChipView-51 to be able to download the 
application to your target system, set breakpoints and single step, you must 
modify the hardware so that some of your CODE and DATA address space 
overlap.  Ordinarily, the physical ROM space where the CODE is to be 
downloaded to would be populated with RAM chips.  By inserting the PromICE 
into the ROM socket and connecting the WRITE line to the PromICE, the 
monitor can be downloaded into the PromICE and the rest of the CODE space 
can be written to.  This still requires overlapping CODE and DATA space, 
but it isn't necessary to add an extra socket to your target system (one 
for the monitor and one for overlapped CODE) when using the PromICE.

This requires a hardware modification to your target system.  One way of 
implementing this configuration is to dedicate a port pin to be used to 
set the overlay only when you want to write to ROM.  By redirecting the 
write signal to the ROM address space you can then use the RAM as ROM 
(so when you do a write to the ROM space, it doesn't do a write to the 
same address in RAM and when you do a read, it will only be from RAM), 
and then clear the bit to put things back to normal.

If you overlap all of RAM and ROM space you must be careful that you don't 
write over your monitor code.  If this happens your target and/or host 
will lock up.  If this happens you will have to reload the monitor and 
start over.


If you would like more information about this or any other product 
please contact your Grammar Engine Sales Representative at (800) 776-6423.