This addendum contains the following sections:
Introduction
Executable Names
Supported Features
Restrictions
RISM 51
Introduction to RISM
Serial Communication
RISM Commands
TASKING ROM Monitor
Resources used by ROM Monitor
Serial Communication
Building the ROM Monitor
Source Code Organization
Building the Example Monitors
Retargeting the ROM Monitor
Monitor Configuration
Linker Control File
Programming the EPROMs
Using the ROM Monitor
The ROM Monitor and CrossView Pro
Breakpoints
Monitor Commands
Command Line Editing
Command Syntax
Command Overview
Command Description
Error Messages
This addendum contains information specific to the ROM monitor versions of CrossView Pro for the 8051. A TASKING ROM monitor and a RISM (Reduced Instructions Set Monitor) is available.
CrossView Pro ROM is a ROM monitor-based source level debugger for debugging real-time embedded C and assembly programs. CrossView Pro ROM integrates two separate debugging components. The figure below shows these two components and how they communicate with each other.
Figure Rom-1: CrossView Pro ROM hardware configuration
The first component is CrossView Pro, the source level debugger that runs on the host development system. CrossView Pro translates the low level target information obtained from the embedded ROM monitor to the C and assembly language source level. CrossView Pro has both a powerful command language to control the target's execution and a multi-window user interface to display target and debugging information.
The second component of CrossView Pro ROM is the ROM monitor, also referred to as the target monitor. The ROM monitor is a low level debugging program that normally resides in ROM on the target board and runs directly on the target microprocessor. The ROM monitor must be running on the target board at CrossView Pro startup time. The ROM monitor includes a serial communications interface that lets it accept and interpret commands from CrossView Pro.
The ROM monitor has the general capability to:
The following CrossView Pro executable is delivered with the package (for PC with .exe extension):
xfw51 CrossView Pro Debugger for the 8051
A LAN version of the CrossView Pro debugger for the 8051 is also available. Please contact your local TASKING representative for more information.
Except for the restrictions mentioned in the next section, the debugger cleanly supports the standard features of CrossView Pro, including single stepping, code breakpoints, data breakpoints, trace support, C expression evaluation and record/playback capability.
Facilities for background mode, coverage and profiling are absent in both the TASKING monitor and RISM. The transparency mode is not available for RISM. As a consequence, the CrossView Pro commands CB, st, u, and wt for background mode, and the o command for transparency mode (RISM) are not available. Also, the debugger does not support command line function calling.
The C compiler cc51 has an option, -gr, which you can use to insert two NOP instructions at the beginning of each C line, carrying high level language debug information. When you use this option, a software breakpoint (LCALL monitor) can be set on every C line, without having executed anything of that line.
cc51 -s -gr test.c -o test.src asm51 test.src
Note that CrossView Pro ROM checks and refuses overlapping breakpoints. With the option -gl, the compiler no longer suppresses debugging information for (compiler generated) local assembler labels. This option is useful in combination with the CrossView Pro ROM debugger, which does not allow a software breakpoint (3 byte JMP MONITOR) to be overlapped with a label. So, when -gl is used, CrossView Pro can do a better job, allowing software breakpoints on safe places only. Please note that the amount of debug information in the absolute output file will be increased, which might increase the loading time of the debugger.
When using a ROM monitor based execution environment (e.g., CrossView Pro ROM), we recommend using -grl.
cc51 -s -grl test.c -o test.src asm51 test.src
CrossView Pro ROM can be used with any 8051 evaluation board, running RISM XA (Reduced Instruction Set Monitor). Crossview Pro communicates with the monitor on the target board via a RS232 interface, using a very efficient binary protocol. The resources used by the monitor program are kept to a minimum: it only uses 16 bytes of internal RAM, 3 Kbyte of code, one timer and the serial interrupt.
RISM uses a number of internal registers (not in the sense of hardware registers) and flags. The most important registers are: a 32-bit DATA register containing all data sent from and to the host, a 16-bit ADDR register containing a memory address, SFR address or register address, and a SELECTOR byte defining which type of memory to be accessed.
The SELECTOR byte can have the following values:
For any command accessing a certain type of memory it is necessary to set the SELECTOR byte to the right value. Thus, to get the value of register R7, the SELECTOR byte should contain 01 and the ADDR-register should contain the value 7. A READ_WORD command will then retrieve the value of R7.
CrossView Pro communicates with the RISM51 monitor residing on the target board using a serial connection. No hardware handshaking is used, so only the signals TxD, RxD, DTR and GND need to be connected. The DTR signal is used to reset the target board. The default baud rate is 9600.
Upon reset RISM runs an initialization section of code and enters the diagnostic mode. At this point one of two bytes ('/' or '\') can be sent to leave diagnostic mode and enter command mode. In command mode RISM will wait for characters across the serial port. A received character can either be actual data or a RISM command.
RISM commands can have values between 00 and 1FH, data can have any byte-value. To distinguish the lower data values from matching commands these data values should be prefixed by sending a SET_DLE command, this command will set the internal DLE flag. When this flag is set the next received character will be interpreted as a data-value instead of being interpreted as a command.
The following table shows a list of all RISM commands:
Code | Name | Description |
00 | SET_DLE | Force the next byte received to be treated as data instead of being treated as a command |
01 | XMIT | Transmit the low byte of the 32-bit DATA register to the host, right shifting it one byte |
02 | XMITA | Same as Xmit, but also increment the ADDR register by one |
03 | WRITE_BYTEA | Store the least significant byte of the DATA register in the byte of memory pointed to by the ADDR register, and increment the ADDR register by one |
04 | READ_BYTE | Read the byte of memory pointed to by the ADDR register and place it in the least significant byte of the DATA register |
05 | READ_WORD | Read the word of memory pointed to by the ADDR register and place it in the least significant word of the DATA register |
06 | READ_LONG | Read the double-word of memory pointed to by the ADDR register and place it in the DATA register |
07 | WRITE_BYTE | Store the least significant byte of the DATA register in the byte of memory pointed to by the ADDR register, and increment the ADDR register by one |
08 | WRITE_WORD | Store the least significant word of the DATA register in the wordof memory pointed to by the ADDR register, and increment the ADDR register by two |
09 | WRITE_LONG | Store the DATA register in the double-word of memory pointed to by the ADDR register, and increment the ADDR register by four |
0A | DATA_TO_ADDR | Load the ADDR register with the DATA register |
0B | INDIRECT | Read the memory double-word pointed to by the ADDR register and save it in the ADDR register |
0C | READ_PSW | Load the low word of the DATA register with PSW and PSW1 (PSW will be loaded to the least significant byte) |
0D | WRITE_PSW | Load PSW and PSW1 with the low word of the DATA register (PSW will be loaded with the least significant byte) |
0E | READ_SP | Load the DATA register with the SP (Stack Pointer) register |
0F | WRITE_SP | Load the SP (Stack Pointer) register with the DATA register |
10 | READ_PC | Load the DATA register with the user_PC (Program Counter) register |
11 | WRITE_PC | Load the user_PC (Program Counter) register with the DATA register |
12 | GO | Start execution of the user code at the address in the user_PC register |
13 | HALT | Stop execution of user code and return to RISMs "Monitor_pause" |
14 | REPORT |
Load the lowest byte of the DATA register with status in formation, which is transmitted back to the host (status values are: 00=stopped, 01=running, 02=trapped (at break) |
15 | RESERVED | |
16 | RESERVED | |
17 | READ_BAUD | Write the Baud_rate register to the DATA register |
18 | WRITE_SELECTOR | Loads the SELECTOR byte with the lowest byte of the DATA register. Valid selector register values are: 01 for REG's, 08 for SFRs and 00 for other memory locations |
19 | READ_BIT | Read a bit value to the DATA register |
1A | WRITE_BIT | Write the value of the DATA register to a bit |
1B | STEP | Step one instruction of user code |
1C | WRITE_BAUD | Write the DATA register to the Baud_rate register and set the baud rate |
1D | READ_FREQUENCY | Read the value of the frequency from SYS_freq to the DATA register |
1E | REPORT_DEVICE | Load the low byte of the DATA register with DEVICE_ID |
1F | EXIT |
Table Rom-1: RISM commands
The monitor program consists of approximately 3 K of code. The start address depends on the target board design, but the most common position is address 0000H, because the RESET vector is located there.
The internal data requirements are kept to a minimum. The monitor only uses one register bank, the one you selected with MON_REGBANK in a monitor configuration file (default 3), and 20 bytes of stack space. In addition, 12 bits in bitaddressable memory are used.
All other monitor data is stored in external data memory. To keep memory access efficient, short addressing is used. In this addressing mode, the contents of the P2 register is used for the upper 8 bits of the data address. The P2 register will be initialized at monitor startup and should not be changed by a user program. The number of bytes used in XDATA memory is approximately 76 bytes.
The CODE and XDATA address spaces are assumed to be identical. For instance, when the monitor needs to set a breakpoint, it is written in XDATA memory, because there are no instructions to write into CODE memory.
CODE XDATA BIT DATA (stack) Register bank |
3 K bytes 76 bytes 12 bits 20 bytes 8 bytes |
Interrupt vectors (high priority level) |
IE0 RI+TI |
Peripherals |
timer1 (TH1, TL1 and part of TMOD/TCON) SCON, SBUF P2 |
Table Rom-2: ROM monitor resources
You should use the link51 RESERVE control to prevent the linker from locating sections in the code, register bank, and data regions of the monitor. In the subdirectory xvw of the examples directory a (makefile) is present showing which areas to reserve for some evaluation boards. This directory also contains all files to build the demo program.
For example, for the Ceibo 552 evaluation board the following areas should be reserved:
RESERVE( CO(03H,07FFFH), XD(0H,0BFFFH), XD(0FF00H,0FFFFH), DA(18H,1FH), DA(06CH,07FH), BI(0H,0EH) )
Please note that the cstart.asm file must be preprocessed with the following define:
-DMON51=TASKING
This affects the following CSTART items:
- Interrupts are NOT disabled, before calling main(), keeping the serial line interrupt of MON51 alive. You should not disable interrupts in your application.
- Internal RAM is NOT cleared.
- Port P2 is NOT cleared.
CrossView Pro communicates with the ROM monitor residing on the target board using a serial connection. No hardware handshaking is used, so only the signals TxD, RxD and GND need to be connected. The software uses the X-on/X-off flow control protocol to prevent overruns. The default communication parameters are: 9600 bps, 8 data bits and no parity.
The ROM monitor uses an ASCII protocol, so it is possible to use the monitor with a dumb terminal only. From within CrossView Pro, direct communication with the ROM monitor is also possible using the transparency mode. See the section Transparency Mode in chapter Special Features for information on how to use the transparency mode.
The monitor input is interrupt driven. Incoming characters are first stored in a circular input buffer. When the monitor is ready to accept new input, it reads from this input buffer. When the circular buffer fills up to some configurable number of characters (the high water mark), an X-off character is sent to the host. When the host does not stop sending and the input buffer fills up completely, the excess characters are ignored. When the monitor reads from the input buffer and the number of characters in the buffer decreases to the low water mark, an X-on character is sent to restart the host.
The monitor output may be stopped by sending an X-off character (^S), and restarted with an X-on (^Q). The monitor or a running user program may be interrupted at any time with the ^C character.
The 8051 monitor is completely written in assembly language. It consists of a number of assembly sources modules (.asm suffix), some include files (.inc suffix) and a number of linker control files (.ctl suffix) for various configurations.
In addition, there are a number of configuration files (.cfg suffix), that contain configuration information for a number of different hardware environments. In order to configure the monitor for one of these environments, you have to copy one of the configuration files to the include file config.inc. Also a Makefile is present to create the sample monitors.
The monitor source code consists of the following files:
File | Description |
break.asm | breakpoint handling |
command.asm | general monitor commands |
data.asm | data allocation |
mem.asm | memory dump/modify commands |
mon51.asm | main monitor entry point and command loop |
serial.asm | serial I/O module |
srec.asm | S-record downloading |
util.asm | various utility functions |
const.inc | various monitor constants |
define.inc | macro definitions used in extern.inc |
extern.inc | external symbol definitions |
ceibo.ctl | linker control file for the Philips Ceibo evaluation board |
intelgb.ctl | linker control file for Intel EV80C51GB evaluation board |
mcb.ctl | linker control file for Siemens MCB-517 evaluation board |
sibec.ctl | linker control file for Sibec-51 evaluation board |
ceibo.cfg | configuration for the Philips Ceibo evaluation board |
intelgb.cfg | configuration for Intel EV80C51GB evaluation board |
mcb.cfg | configuration for Siemens MCB-517 evaluation board |
sibec.cfg | configuration for Sibec-51 evaluation board |
Makefile | makefile to build the sample monitors |
README | additional information about the ROM monitor |
Table Rom-3: ROM monitor files
You can use the Makefile with the "make" utility mk51 to build the example monitors. Before issuing the commands described below, you will have to go to the directory mon, where the monitor sources are located.
The Makefile accepts a macro on the command line to specify the target. If you do not provide a target, the default is mcb. The following targets can be used:
TARGET=mcb # MCB-517 target board TARGET=ceibo # CEIBO target board TARGET=intelgb # Intel CV80C51GB target board TARGET=sibec # Sibec-51 target board with # emulator
To create, for example, the monitor for the Ceibo evaluation board, use the command:
mk51 TARGET=ceibo
This command creates the Motorola S-record file ceibo.sre, which can be programmed into an EPROM.
How the monitor is built is described below. You can use it as a guideline to build a retargeted monitor.
A configuration file contains configuration information for a specific evaluation board. See section 6.3.3.1 , Monitor Configuration,for detailed information. In order to configure the monitor for one of the delivered environments, one of the configuration files (.cfg suffix) must be copied to the include file config.inc. This file and the other delivered include files are included by the assembly source files (.asm suffix).
The .asm files must be preprocessed by mpp51 and then assembled by asm51. For example, to create the object file break.obj, the following commands are needed:
mpp51 break.asm asm51 break.src
When all .asm files are assembled, the resulting object files must be linked into an output file. The most convenient way of invoking the linker link51 is by using a linker control file. A linker control file holds all the required arguments for the linker. It contains the list the object files and the linker directives to control the memory layout of the code and data sections. The delivered .ctl files can be used to link the monitor for one of the supported hardware environments. For instance, to link the monitor for the Ceibo evaluation board, use the command:
link51 @ceibo.ctl
Warnings produced by the linker about XDATA overlaps can be ignored.
The resulting .out file may be converted into Motorola S-records with the srec51 command. In our example, the command would be:
srec51 ceibo.out ceibo.sre
The S-record file may then be programmed into an EPROM
Adapting the monitor to a new hardware environment involves the creation of a new config.inc file with configuration items, and a new linker control file, describing the memory layout. The next two sections describe these two tasks.
To adapt the monitor to a different hardware environment, you have to create a custom version of the file config.inc. The delivered .cfg files may serve as examples. Copy one of the configuration files (.cfg) listed in Table Rom-3 to the file config.inc.
A configuration file consists of a number of mpp51 macro definitions. These macros are used to conditionally include assembly code or they are used to define constants and addresses. This section describes the individual configuration items in detail:
This macro defines the length of the buffer used to store the next command, including the terminating carriage return. A command that does not fit in the command line buffer is truncated.
The command line buffer is also used to store converted S-records during downloading. To be able to download S-records containing x data bytes, the size command line buffer must be as least x+3 bytes. The default size is 35, which is sufficient for S-records with 32 data bytes.
The default definition for this macro is 1, which means that command abbreviation is enabled. When ABBREVIATION is 0, each command has to be specified completely.
The register bank used by all monitor code. Defaults to 3.
When COPYVECTORS is 0, the interrupt vectors for the INT0 interrupt is located at address 0003H and the serial I/O interrupt is located at addresses 0023H. This is the correct setting when the monitor is to be put in an EPROM at address 0000H.
COPYVECTORS may be set to 1 to enable run-time installation of these two interrupt vectors in XDATA space at address 0003H and 0023H.
This configuration item is only used when COPYVECTORS is 0. It specifies the address of a user installable interrupt vector for the timer 0 interrupt (TF0).
When VECTOR_TF0 is non-zero, a jump instruction at CODE address 000BH is included in the monitor, which jumps to the address specified by VECTOR_TF0. A user program may install a private interrupt vector at this location, provided the memory is mapped as both CODE and XDAT. Three bytes are allocated for the user interrupt vector, which is sufficient for a LJMP instruction.
This configuration item is only used when COPYVECTORS is 0. It specifies the address of a user installable interrupt vector for the external interrupt 1 (IE1).
When VECTOR_IE1 is non-zero, a jump instruction at CODE address 0013H is included in the monitor, which jumps to the address specified by VECTOR_IE1. A user program may install a private interrupt vector at this location, provided the memory is mapped as both CODE and XDAT. Three bytes are allocated for the user interrupt vector, which is sufficient for a LJMP instruction.
Defines the address of a 3 byte memory region that is mapped as both XDATA and CODE memory. The memory will be used by the monitor to execute run-time generated code to read or write SFR registers.
Set this macro to 1 when you are using the 80C517/80C537 family of 8051 derivatives. These CPUs use the SFR registers IP0 and IP1 instead of IP, to control the interrupt priority. In addition, the addresses of these registers have to be defined:
IP0 DATA 0A9H ; interrupt priority 0 IP1 DATA 0B9H ; interrupt priority 1
Set this macro to 1 when you are using the 80C517/80C537 family of 8051 derivatives and you want the serial port 1 to be used by the monitor.
Use this macro to define the commands to use for a watchdog timer for 8051 derivatives that use one. For example, for the 80C51GB the WATCHDOG macro must contain the commands:
MOV 0a6H,#01eH MOV 0a6H,#0e1H
The maximum number of characters in the the circular input buffer is defined by this macro. One extra byte is allocated in order to be able to distinguish a full from an empty buffer. How large this buffer should be to prevent overruns, depends on how fast the host reacts on an X-off control character that is send when the high water mark is reached (see below). The size of the input buffer should be at least 1.
This macro defines the number of characters that may be stored in the input buffer before an X-off character is send to the host. When the HIGH_WATER_MARK is set to 0, flow control is effectively disabled.
This macro defines the size of the input buffer where an X-on character is transmitted to restart the host. The X-on is transmitted only when an X-off was previously sent. The LOW_WATER_MARK must be lower than or equal to the HIGH_WATER_MARK.
These two macros define the parameters for the baud rate generator of the serial port. The SERIAL_TH1 value is loaded into the TH1 timer register, and the SERIAL_SMOD value is loaded into the SMOD bit of the PCON register. When SMOD is set to 1, the baud rate is doubled. The actual baud rate depends on the operating frequency of the CPU. The following table lists some configurations:
fOSC | Baud rate | SMOD | TH1 |
11.0592 | 1200 | 0 | 0E8H |
11.0592 | 2400 | 0 | 0F4H |
11.0592 | 4800 | 0 | 0FAH |
11.0592 | 9600 | 0 | 0FDH |
11.0592 | 19200 | 1 | 0FDH |
Table Rom-4: SMOD, TH1 settings
Some 8051 derivatives (e.g. 80C517/537) have a built-in baud rate generator which is able to generate standard speeds using a 12.0 MHz processor clock. Setting the SERIAL_BD macro to 1 enables the use of this baud rate generator. The SERIAL_TH1 value is not used in this case. The following table lists the available baud rates using a 12.0 MHz clock:
fOSC | Baud rate | SMOD | BD |
12.0 | 4800 | 0 | 1 |
12.0 | 9600 | 1 | 1 |
Table Rom-5: SMOD, BD settings
This macro defines the parameter for the baud rate generator of the serial port 1 within the 80C517/80C537 derivatives. You only need to set the SERIAL_SREL macro to a correct value when SERIAL1 is set to 1. The following table lists some configurations:
fOSC | Baud rate | SREL |
12 | 9600 | 0D9H |
12 | 4800 | 0B2H |
12 | 2400 | 064H |
11.0592 | 19200 | 0EEH |
11.0592 | 9600 | 0DCH |
11.0592 | 4800 | 0B8H |
11.0592 | 2400 | 070H |
Table Rom-6: SREL settings
You can use one of the delivered linker control files (.ctl suffix) as a starting point for a new linker control file for your hardware environment. The only modifications necessary are the base addresses of the CODE and IDATA sections, and the RESERVEd areas in XDATA memory.
When you set the CODE base address to 0000H, you should disable the COPYVECTORS configuration option. Otherwise, enable it.
Make sure that all relocatable XDATA sections are located in the same 256 byte page, because all monitor data must be within the same page (P2 is fixed).
The IDATA sections is used for the stack. You probably want to set this as high as possible.
If you use the same basename for your linker output file (.out suffix), your linker control file (.ctl suffix) and your customized configuration file has the same basename with .cfg suffix, you can use the existing Makefile to build the retargeted monitor. You customized files must be located in the same directory as the monitor sources.
For example, if your configuration file is called myboard.cfg, your linker output file (specified in the linker control file) is called myboard.out and your linker control file is called myboard.ctl, you can build the retargeted monitor by issuing the following command:
mk51 TARGET=myboard
After the desired monitor image has been created, it has to be burned into one ore more PROM or EPROM chips.
Before programming the chips you should check the PROM's documentation to make sure it is compatible with the target board. Also check if the chips have the correct speed and that they are supported by the PROM programmer.
Please consult the PROM programmer's documentation to learn how to create the prospective PROMs, since each programmer has its own way of operation.
Transparency mode allows you to communicate directly with the ROM monitor. Most of the time CrossView Pro can handle all of the low level communications, freeing you to concentrate on the high level language C code.
To enter transparency mode, type:
xvw>o
Now all of your following commands will be received directly by the ROM monitor.
To exit transparency mode, type ctrl-D (the end-of-file character). This brings you back to the CrossView Pro prompt.
When entering transparency mode, CrossView Pro removes any breakpoints it may have established in the target code. This ensures that you can access unmodified target code. CrossView Pro re-establishes breakpoints if necessary when transparency mode ends.
Upon exit from transparency mode, CrossView Pro re-establishes control over certain aspects of the ROM monitor which it needs. As long as you avoid the debugger's own breakpoint exception, you may establish breakpoint conditions in transparency mode. These will remain active after you exit transparency mode. If one of these breakpoints is hit, then CrossView Pro issues a message like:
Stopped on a breakpoint not set by the debugger.
If a breakpoint is present and enabled at the current value of the PC, it will not be disabled or removed, but stepped off with a single step. The breakpoint will remain present and enabled though.
You can use the -grl option of cc51 when you compile your C sources, to insert two NOP instructions before each C line to allow software breakpoints on each C line. See the section Restrictions for more information.
Before reading the next command, the monitor issues a prompt: "* ". Each command line is first stored in a command line buffer, before it is interpreted. This allows for some limited command line editing. All printable characters are echoed, and the following control characters are interpreted:
All other control characters are ignored. The length of the command line buffer is limited to 35 characters to conserve XDATA space, but it is configurable when the monitor is rebuilt from the source code.
Every monitor command consists of one command word, optionally followed by one or more numerical arguments or keywords, separated by one or more spaces. Each command word may be abbreviated by using an arbitrary prefix. When two commands have a common abbreviation, the first matching command is used. Both lower and upper case characters are accepted. All numerical arguments of the monitor commands must be specified using hexadecimal notation.
Next is a list of the available monitor commands, together with their minimum abbreviation:
Command | Abbreviation | Description |
ACC | A | Get/set accumulator 1) |
B | B | Get/set mul/div accumulator |
DPTR | DP | Get/set data pointer 1) |
IE | IE | Get/set interrupt enable register 1) |
IEN1 | IEN1 | Get/set interrupt enable register 1 1) |
IEN2 | IEN2 | Get/set interrupt enable register 2 1) |
PC | P | Get/set program counter 1) |
PSW | PS | Get/set processor status word 1) |
SP | SP | Get/set stack pointer 1) |
TCON | TCO | Get/set TCON register |
Table Rom-7: Register commands
1) These commands manipulate a copy of the register, not the register itself. The copy is loaded into the real register when the user program is started.
Command | Abbreviation | Description |
CBYTE | C | Display/modify CODE memory |
DBYTE | D | Display/modify DATA memory |
RBYTE | R | Display/modify SFR memory |
XBYTE | X | Display/modify XDATA memory |
Table Rom-8: Memory commands
Command | Abbreviation | Description |
GO | G | Start user program |
SBR | SB | Show/set software breakpoint |
STEP | S | Single step user program |
XBR | XBR | Set external breakpoint |
XGO | XG | Start user program; suppress register dump |
XSTEP | XS | Single step user program; suppress register dump |
Table Rom-9: Execution commands
Command | Abbreviation | Description |
ECHO | EC | Echo string |
LO | LO | Load S-record file |
REG | RE | Display user register |
RESET | RES | Simulate a hardware reset |
TEST | TE | Test memory |
VER | V | Display monitor version |
Table Rom-10: General commands
This section describes the exact syntax of all monitor commands. Command names and additional keywords, like ON, OFF, TO etc., may be specified in both upper and lower case. The following syntax is used for operands:
Operand | Description |
byte | An 8-bit value. |
word | A 16-bit value. |
addr8 | An 8-bit address. |
addr16 | A 16-bit address. |
cr | A newline. |
text | Arbitrary text. |
Table Rom-11: Command description
Optional portions of a command are written between '[' and ']'. An optional part that may be repeated a number of times, is written between '[' and ']...' .
ACC
ACC = byte
A
When used without arguments, this command displays the current contents of the ACC register. In the second format, the register is set to the new value byte.
This command operates on a copy of the register, not
the actual register itself. The value is loaded into the real register when the
user program is started.
B
B = byte
B
When used without arguments, this command displays the current contents of the B register. In the second format, the register is set to the new value byte.
CBYTE addr16
CBYTE addr16 TO addr16
CBYTE addr16 = byte [ , [ cr
] byte ]...
CBYTE addr16 TO addr16 = byte
C
This command displays, or modifies bytes in CODE memory. Because it is not possible to write to CODE memory, the monitor accesses XDATA memory instead. The only difference with the XDATA command is that the OPR register is first loaded with the value of the IPR register.
The first format of this command displays 1 byte. In the second format, bytes from the first address up to and including the second address are displayed. At most 16 bytes are displayed on one output line.
The third format is used to store one or more bytes into consecutive memory locations. The command may be continued onto the next line by typing RETURN after a comma.
The fourth format is a memory fill command. The byte is stored in memory from the first address up to and including the second address.
DBYTE addr8
DBYTE addr8 TO addr8
DBYTE addr8 = byte [ , [ cr
] byte ]...
DBYTE addr8 TO addr8 = byte
D
This command displays, or modifies bytes in internal DATA memory.
Note that IDATA (indirect data memory) is used if 80h <= addr8 <= ffh.
The first format of this command displays 1 byte. In the second format, bytes from the first address up to and including the second address are displayed. At most 16 bytes are displayed on one output line.
The third format is used to store one or more bytes into consecutive memory locations. The command may be continued onto the next line by typing RETURN after a comma.
The fourth format is a memory fill command. The byte is stored in memory from the first address up to and including the second address.
DPTR
DPTR = addr16
DP
When used without arguments, this command displays the current contents of the DPTR register. In the second format, the register is set to the new value addr16.
This command operates on a copy of the register, not
the actual register itself. The value is loaded into the real register when the
user program is started.
ECHO text
EC
Echoes text back to the host. This command is used by CrossView Pro for synchronization purposes.
GO [ FROM addr16 ] [ TILL addr16 ]
G
Start the user program. When the FROM address is present, it is first loaded into the user PC. When the TILL address is present, a temporary software breakpoint is set.
The SBR software breakpoint is inactive when the user
program is started with a GO ... TILL addr16 command. However,
when the user program returns, the SBR breakpoint is restored.
IE
IE = byte
IE
When used without arguments, this command displays the current contents of the IE register. In the second format, the register is set to the new value byte.
This command operates on a copy of the register, not
the actual register itself. The value is loaded into the real register when the
user program is started.
IEN1
IEN1 = byte
IEN1
When used without arguments, this command displays the current contents of the IEN1 register. In the second format, the register is set to the new value byte.
This command operates on a copy of the register, not
the actual register itself. The value is loaded into the real register when the
user program is started.
IEN2
IEN2 = byte
IEN2
When used without arguments, this command displays the current contents of the IEN2 register. In the second format, the register is set to the new value byte.
This command operates on a copy of the register, not
the actual register itself. The value is loaded into the real register when the
user program is started.
LO
LO
Load an Motorola S-record file into memory. Only S0, S1 and S9 records are supported. Every valid S-record is acknowledged by a dot. An incorrect record is signalled by a question mark.
PC
PC = addr16
P
When used without arguments, this command displays the current contents of the PC register. In the second format, the register is set to the new value addr16.
This command operates on a copy of the register, not
the actual register itself. The value is loaded into the real register when the
user program is started.
PSW
PSW = byte
PSW
When used without arguments, this command displays the current contents of the PSW register. In the second format, the register is set to the new value byte.
This command operates on a copy of the register, not
the actual register itself. The value is loaded into the real register when the
user program is started.
RBYTE addr8
RBYTE addr8 TO addr8
RBYTE addr8 = byte [ , [ cr
] byte ]...
RBYTE addr8 TO addr8 = byte
R
This command displays, or modifies bytes in SFR memory.
Note that DATA (direct data memory) is used if 0h <= addr8
<= 7fh. See also the DBYTE command.
The first format of this command displays 1 byte. In the second format, bytes from the first address up to and including the second address are displayed. At most 16 bytes are displayed on one output line.
The third format is used to store one or more bytes into consecutive memory locations. The command may be continued onto the next line by typing RETURN after a comma.
The fourth format is a memory fill command. The byte is stored in memory from the first address up to and including the second address.
REG
RE
Displays the current user registers PC, PSW, SP, A, B and R0 through R7. The output format is the same as generated after a single step.
RESET
RES
Simulate a hardware reset and restart the monitor. All user registers are initialized to their RESET value.
SBR
SBR = OFF
SBR = addr16
SB
When used without arguments, this command displays the current software breakpoint address, or OFF when the software breakpoint is currently not defined. The second format disables the software breakpoint. The third format defines a new software breakpoint address.
The SBR software breakpoint is inactive when the user
program is started with a GO ... TILL addr16 command. However,
when the user program returns, the SBR breakpoint is restored.
SP
SP = byte
SP
When used without arguments, this command displays the current contents of the SP register. In the second format, the register is set to the new value byte.
This command operates on a copy of the register, not
the actual register itself. The value is loaded into the real register when the
user program is started.
STEP [ FROM addr16 ] [ word ]
S
Perform word single steps (default 1) of the user program. When the FROM address is present, it is first loaded into the user PC.
TCON
TCON = byte
TCO
When used without arguments, this command displays the current contents of the TCON register. In the second format, the register is set to the new value byte.
TEST addr16 TO addr16
TE
Perform a simple destructive memory test in the memory range from the first address up to and including the second address. When an error is detected, the address is reported and the memory test is aborted.
VER
V
Display the monitor version.
XBR = addr16
XBR
Write a breakpoint into memory and report the 3 bytes replaced. The breakpoint is not administered by the monitor. This command is intended to be used by the CrossView Pro debugger.
XBYTE addr16
XBYTE addr16 TO addr16
XBYTE addr16 = byte [ , [ cr
] byte ]...
XBYTE addr16 TO addr16 = byte
X
This command displays, or modifies bytes in XDATA memory.
The first format of this command displays 1 byte. In the second format, bytes from the first address up to and including the second address are displayed. At most 16 bytes are displayed on one output line.
The third format is used to store one or more bytes into consecutive memory locations. The command may be continued onto the next line by typing RETURN after a comma.
The fourth format is a memory fill command. The byte is stored in memory from the first address up to and including the second address.
XGO [ FROM addr16 ] [ TILL addr16 ]
XG
The XGO command behaves like the GO command, except for the suppression of the register dump when the monitor is reentered. This command is used by the CrossView Pro debugger to minimize the communication with the monitor.
XSTEP [ FROM addr16 ] [ word ]
XS
The XSTEP command behaves like the STEP command, except for the suppression of the register dump when the monitor is reentered. This command is used by the CrossView Pro debugger to minimize the communication with the monitor.
The monitor has only two different error messages. These messages are:
This error message is issued when the first word on the command line is not recognize as a valid command, or command abbreviation.
This error is issue when the command is recognized, but there is something wrong with the arguments. E.g.: missing argument, unexpected argument, invalid numerical argument, etc.