Introduction

Introduction

MCS8051.DLL models the standard 80C51 and 80C52 variants of the 8051 CPU family as well as a smattering of variants from manufacturers. Support for other 8051 variants may be added in the future - please tell us what you are using.

The 8051 Datasheet contains full details of how to program the 8051 processor.

Properties

The 8051 model supports the following properties:

Property | Default | Description
PROGRAM | - | Specifies one or more program files to be loaded into the model's internal code memory. The files can be either Intel hex files or OMF51 absolute object module format files. Use commas to separate multiple file names. See Specifying The Program File for more information.
CLOCK | 1.2MHz | Specifies the clock frequency of the processor. For reasons of efficiency, the clock circuitry is not simulated, and the clock rate of the processor is determined solely by this value.
DBG_FETCH | FALSE | If TRUE, causes the model to simulate external program fetches. This mode of operation is extremely slow, but will allow you to test external program memory decode circuitry.
DATARAM | - | Specifies regions of the memory map that correspond to external data RAM. This allows for much faster simulation of external memory accesses. See Modelling the Memory Map for more information.
CODERAM | - | Specifies regions of the external memory map that are shared between code and data (i.e. von-neumann decoding). See Modelling the Memory Map for more information.

Keil µVision Debug Monitor Driver

The MCS8051 model contains special support code to provide source level debugging with the Keil µVision 2 development environment. For installation instructions click here.


MODELLING THE MEMORY MAP

By default, all external data memory accesses are fully modelled. That is to say that each external data memory cycle involves simulating the numerous transitions of ALE and the P0 and P2 port pins. A typically cycle will involve around 50 pin state transitions is thus vastly expensive in terms of simulation time.

In contrast, all program memory cycles are simulated internal to the 8051 model - that is to say that the program bytes are looked up in a memory buffer internal to the chip and no pin-state transitions are simulated. This is the case irrespective of the amount of internal ROM available on a particular 8051 part, and is done in order to achieve reasonable simulation speeds. This optimization can be disabled by specifying:

DBG_FETCH=FALSE

For applications which make extensive use of external data RAM, two further optimizations can be specified.

DATARAM Property

This specifies regions of the external memory map which can be treated as RAM and simulated internally to the 8051 model. A typical example would be:

DATARAM=0000-7FFF,C000-FFFF

This would specify two regions of external data memory.

CODERAM Property

Where regions of the external memory map are wired in a Von-Neumann configuration (external data memory and code memory are the same), this can be specified as follows:

CODERAM=0000-7FFF

Any external memory writes to the region 0000-7FFF will then 'write through' to the internal program memory buffer of the model and be 'seen' by subsequent instruction fetches and MOVC instructions.


Specifying the Program File

The 8051 model can load program files in OMF51 format as well as the exact same hex file that you would program a physical device with. The advantage of using the debug format is that it contains symbolic debug information (source code, variables,etc.) which enables you to not only simulate your system in Proteus but also to single step debug. The following is a summary of supported formats with basic instructions on how to get started.

See Also:

Proteus VSM Tutorial

VSM Studio IDE

By far the easiest way to get set up for simulating in Proteus is through the integrated VSM Studio IDE. This tool is integrated into the Proteus Design Suite, will detect installed compilers and you can directly download and install additional tools from inside the IDE.

Installed compilers are automatically configured by VSM Studio to produce debugging output suitable for driving Proteus VSM. If however you need to make changes all of the compiler options are made available in the Project Setting dialogue inside VSM Studio.

Once you have written some code and compiled your schematic will automatically be programmed with the firmware. You can then both simulate and single step debug inside VSM Studio. Active popups let you add 'schematic snippets' to VSM Studio so that you can view and interact with the simulation while debugging the source code.

See Also:

VSM Studio Tutorial (New Project)

Schematic Only

If you choose or prefer to work in your own IDE and use Proteus VSM only for simulation then the 8051 model can load program data from either Intel hex files or OMF51 absolute object module format files. The latter are the default output produced by the Keil C51 compiler. You can specify more that one file within the PROGRAM property as in:

PROGRAM=FILE1.HEX,FILE2.HEX

Using OMF51

Proteus VSM can load files created in the standard OMF51 format and will extract line number information to provide source level debugging. This format is fairly standard in the 8051 world and is supported by most professional compilers.

To debug within Proteus using OMF51, firstly make sure that your compiler generates an output file with the extension ‘OMF’, and then specify that file for the PROGRAM property as in

PROGRAM=MYFILE.OMF

Please note that the Keil compiler creates an OMF file with no extension as its default option so you must change this in the Project Options before you can use the file with Proteus. The output filename is specified in the Output tab. However, if you are using the Keil IDE, you will probably prefer to use the AGDI debugger driver anyway.


Virtual Debug Monitor for Keil uVision

Debug Monitor for Keil mVision

Introduction

The 8051 model includes special code that enables it to integrate with the Keil µVision2 development environment. Specifically, the model implements an AGDI Driver which enables the Keil environment to control the simulated CPU over a TCP/IP link. The result is that you can develop a program in UV2 (using C51 and/or A51) and then single step it as it runs on a simulation of your hardware under Proteus VSM. Think of it as In-Circuit Emulation without any physical hardware.

If you have two machines connected by a TCP/IP network you can run the debugging environment on one and display the VSM schematic - complete with animated peripherals - on the other.

Basic Installation

The Proteus VSM AGDI Driver should be installed on the computer that will be running UV2, and hence it is not installed by the main Proteus setup program. To download and install the driver click here.

Once you have downloaded and installed the driver you will find some additional documentation is available in the ‘Books’ window of UV2.

Preparing your UV2 Project for Debugging under Proteus VSM

To use the AGDI driver you need to select it as the current debugging tool within your Keil project. To do this:

  • Open your Keil UV2 project and invoke the Options command on the Project menu.
  • Select Debug tab of this dialogue form and change the selection from the Use Simulator option to the Use Proteus VSM Simulator option on the right hand half of the dialogue.
  • If you are planning to run ISIS on a second computer, click the Settings button and enter the IP address or DNS name of the target computer into the Host IP address field.
  • For most purposes it is also sensible to select Load Application at Startup and Go Until Main. If you give the former setting, it is not necessary to specify the program file for the 8051 model, as UV2 will load the program into the 8051 model at the start of each debugging session.

Running a Debugging Session

Once the UV2 project has been prepared for VSM debugging, a typical session will proceed as follows:

  • Load the schematic for your hardware into a copy of ISIS.
  • Invoke the Use Remote Debug Monitor command on the Debug menu. A status message to the effect that the VDM server is running should appear on the status line. If you get error messages, it is most likely that there is a problem with your TCP/IP configuration.
  • Bring UV2 to the foreground and press F5 to start debugging. If all is well, ISIS should enter simulation mode in the paused state, and UV2 should display the first line of your code along with the register values.
  • You can then use the all usual debugging commands within UV2 to control the debugging session.
  • When you stop debugging in UV2, ISIS will exit the simulation automatically.