- Email: [email protected]
Debugging aids for microprocessor systems
Debugging aids for microprocessor systems Lack of powerful incircuit debugging support presents a problem to digital designers. E P Farrell and N G Kanellopoulos discuss two complementary solutions.
Current teaching and research activities at Newcastle University invo/ving microprocessor systems, have shown the need for debugging aids which can be used for efficiently tracking down both hardware and software faults during the deve/opment stage of microprocessor-based digital systems. The paper describes the implementation of two different approaches to this problem, the collective aim being to provide sophistication combined with flexibi/ity. In the DSL (Digital Systems Laboratory) at the University of Newcastle Upon Tyne, numerous projects, using microprocessors, are undertaken by students and research workers. Such projects have included logic testers, data-acquisition/ processing systems and floppy-disc control and management systems. The DSL's microprocessor systems are designed round a basic framework of wire-wrap card¢ holding components such as the MPU (microprocessing unit), peripheral control units and memory elements. This basic framework provides students with flexibility in constructing microprocessor-based digital systems on a general-purpose wiring chassis. The most commonly used microprocessor system in the DSL is the Motorola M6800 family 2. One of the standard modules is a hardware console 3 which was designed for the M6800 system to provide the facilities of memory read/ write access and single-step/go execution control, together with the ability to allow the user to initialize the MPU program counter to any selected value. As shown in Figure 1, this hardware console consists of a general-purpose control panel (based on lights, switches and pushbuttons) and a card holding the necessary logic to interface the panel to the M6800 buses. Software support is provided by the University's time-shared computing facility, based on an IBM 370/168, which gives students access to an M6800 crossassembler and simulator. TWO APPROACH
undertaken 4, s with the overall aim of investigating the implementation of the necessary debugging aids to locate both hardware and software bugs. The first approach is based on a monitor program which is executed by the host MPU and uses as its console an ASCII keyboard and an ordinary TV set. ]-his approach concentrated on providing the sophistication of facilities needed through software control under which user-program status information is continuously displayed on the TV screen; conceptually, the system may be described as a 'software console'. It was necessary to design some supporting hardware to preserve the integrity of the debugging software from corruption by the user's software. This aid was implemented on the M6800 framework described earlier. The second approach uses microprogramming techniques for interfacing the generalpurpose control panel, mentioned earlier, to the system buses of various MPUs (Motorola M6800, Intel 8080, Intersil 6100, etc.) and therefore concentrates on the flexibility of the design. The resulting 'firmware console' provides the same debugging facilities as the 'hardware console'. However if more sophisticated facilities are required, they can be implemented by adding some suitable software which is executed by the host MPU.
ES
To allow the microprocessor systems designed by the students to be debugged efficiently, it was decided that more sophisticated and flexible debugging aids were needed than the existing hardware console. Two projects have been Computing Laboratory, The University of Newcastle upon Tyne, Claremont Tower, Claremont Road, Newcastle upon Tyne NE1 7RU, UK
vol 2
no
2 april 78
Figure I. Hardware
console
83
APPROACH ONE
user program is being executed. The NMI control unit implements the following three functions
It is apparent that at present, due to the lack of powerful software debugging support systems, software development inevitably lags behind hardware development in microprocessor-based digital system design. With this in mind, the Bedbug debugging aid has been designed and is currently running on an M6800 system. Bedbug provides a powerful set of debugging facilities which are easy to use, and are briefly summarized as follows
• •
• • • • • • •
Loads the user program into memory Disassembles memory to check that the program has been loaded correctly Uses either symbols or absolute values to refer to addresses in memory Alters the contents of the user's microprocessor registers Either singlesteps or continuously executes the user program in conjunction with software breakpoints Carries out read/write memory accesses.
Bedbug organization Figure 2 shows a typical user microprocessor system to which Bedbug has been attached during system development. To the left of the dotted line is the user system consisting of an MPU, a memory area for user program/data storage and some I/O ports for user I/O handling; in many cases the user may also attach some special-purpose logic such as a floppydisc controlle~. To the right of the dotted line are the components forming the Bedbug system. The major part of Bedbug is the monitor program which is written in M6800 assembler and resides in 14kbytes of memory. This program implements the debugging facilities provided. The security of the monitor's memory is achieved by using the memory protection unit which is designed to stop the user program writing into the Bedbug memory and also to inform the monitor of such invalid memory write accesses. The interrupt control unit controls the NMI (nonmaskable interrupt) input of the host MPU such that NMI can only be activated when the I User microcomputersystem
'
J
I ports
Microprocessor address +
Bedbug developmentsystem
I program
I I protection I
I memory
I I unit
[11 1 data
I
+__ control buses
_ J
control unit
L=ll
I
h
/
" 1 '
Figure 2. User microprocessor system with Bedbug debugging system attached
84
The Bedbug console consists of two components. First, there is a keyboard, interfaced by an M6820 PIA (peripheral interface adaptor), which allows the user to enter commands and data. Second, there is the output side of the console, a conventional monochrome TV set which is interfaced to the system buses via an alphanumeric video display module 6. This module causes the contents of a 960 byte display memory to be continuously displayed as an image on the screen, using DMA (direct memory access). The module allows the image on the screen to be updated extremely rapidly when any part of display memory has been edited by the Bedbug monitor program. The 24 line by 40 character width display is split into a lower sixline scrolled block for user-Bedbug dialogue, while the upper 18-line section is used by each debugging facility's command subprogram for displaying various types of user program status information. The Bedbug serial output port consists of an M6850 ACIA (asynchronous communications interface adaptor). A hard-copy terminal can be connected to this serial port to obtain a hard copy of the current TV screen image. The final component in the Bedbug system is the paper-tape reader input port which consists of the other half of the keyboard PIA and allows the user object program to be loaded into memory. Bedbug provides 21 commands for the user, each distinguished by a single alphabetical character. The commands fall into three classes • • •
(a) Symbol and breakpoint table management (b) Memory and register access (c) Instruction execution control.
I
I Jinterface ] interface J J video-displayJJinterfaceJ
1
It supports user NMI interrupt handling It allows the user to interrupt his program manually, retain its full status and return control to Bedbug. This is in contrast to the basic RESET function normally provided by simple aids such as Mikbug, which do not stack the user's MPU registers It allows Bedbug to be informed of an invalid memory write access by the user.
Symbols and breakpoints Class (a) commands manage the Bedbug system symbol and breakpoint tables. Commands are provided for symbol/ breakpoint entry or release and also for listing the tables. The symbol table allows the user to make symbolic references to program variables, as he would in his assemblylanguage program, in addition to absolute address references. The breakpoint table enables the user to define multiple software breakpoint addresses; the two techniques used to implement software breakpoints will be described later. A future development will allow a symbol table to be loaded at the same time as the user object code; however, this will require the crossassembler to be modified.
Memory and registers Various class (b) commands are available to enable the user
microprocessors
to access the MPU registers and memory which are used by his program. These include • List memory blocks in hexadecimal format • Write hexadecimal values into memory locations • Disassemble memory to display it in a similar fashion to the assembly-language listing • Enter single machine instructions into memory in assembler format • Display/alter the contents of the user's MPU registers Tl~e disassemble and assemble commands are performed using special instruction information tables holding M6800 assembler information such as instruction size, addressing modes and mnemonic representation. The display/alter register command is implemented by accessing the snapshot of the user MPU registers which is always available on the stack. Finally, all class (b) commands allow symbols to be used in reference to addresses.
IEC (instruction execution control) Class (c) I EC commands allow the user to control program execution in two ways, referred to as 'in-mode' and 'outof-mode'. In-mode IEC causes control to be passed back to the monitor after each user program instruction is executed. This allows the UPSD (user program status display), as shown in Figure 3, to be continually updated. Out-ofmode IEC permits continuous execution of the program without continually updating the UPSD. Both of these modes support user hardware interrupt handling on the IRQ and NMI inputs of the M6800. Program execution may be suspended upon the following occurrences • • • •
Reaching a breakpoint A user invalid memory write access Manually interrupting the user program by pressing a key on the console keyboard A selected memory location changing value (memory trap), this applies to in-mode IEC only
The scheme for switching the MPU between the monitor and user programs uses the instructions, SWI (software interrupt) and RTI (return from interrupt), to push and pop a snapshot of the user register contents to and from the stack. With in-mode IEC the monitor places a SWI trap in the user program at the address of the successor to the next instruction to be executed. It then executes an RTI to reload the register snapshot into the MPU. This causes the next user instruction to be executed, after which the trap is executed causing the new register snapshot to be stacked. On regaining control, the monitor then updates the UPSD and checks for a possible suspension of program execution. Of course, certain instructions require more than one trap to be planted into the user code. However, by using an instruction information table, the monitor can handle special cases such as conditional branch instructions. The memory trap location is monitored by checking the current value of the selected location against the original value it held at the time the user defined the memory-trap address. Finally, in this mode software breakpoints are implemented
vol 2 no 2 april 78
by checking the address of the next user instruction against the current contents of the breakpoint table. In the case of out-of-mode IEC, control is passed directly back to the user program by executing RTI without inserting traps, apart from those which implement software breakpoints. Control is then only returned to the monitor if any of the first three occurrences listed above take place. In conclusion, it is interesting to consider the main problem in implementing Bedbug on other microprocessors. This problem concerns class (c) IEC commands; in principle these are the only ones to be machine dependent. Careful I EC algorithm definition is required to take account of certain machine dependent factors, particularly the interrupt architecture of the MPU. However, such careful definition should allow Bedbug to be implemented on the majority of currently available microprocessors.
SECOND APPROACH Microprocessor manufacturers provide many different types of debugging consoles, offering to the user the ability to interact with his system. However, the majority of these consoles are dedicated to a particular microprocessor product and the user buying such a debugging console is limited to using the corresponding MPU. This limitation is strongly felt in teaching environments, such as the DSL, where different MPUs are frequently employed. What is really needed, therefore, is to investigate the possibility of providing a processor-independent console. This section describes the 'firmware console', an attempt to provide a processor-independent debugging console, utilizing the general-purpose 'control panel' mentioned above. The main innovation is the use of microprogramming techniques to provide the design with the required flexibility. The debugging capabilities of the firmware console are indicated in Table 1. The firmware console may be viewed by a microcomputer system as a peripheral device, which may be used as • a hardware monitor • an I/O device • a controlling device of highest priority
Figure 3. User program status disp/ay
85
Table 1. Debugging facilities of the firmware console • • • • •
(1) Addresses successive memory locations, verifying or changing their content (2) Forces the MPU to start execution from a specified location (3) Controls the processor thus allowing continuous program execution or single instruction execution (4) Traces program execution inserting (a) hardware breakpoints or (b) software breakpoints (5) Displays/alters MPU registers
Figure 4 illustrates the firmware console connected to a user MPU system via the system buses. It consists of two parts, namely the general-purpose control panel (shown also in Figure 1) and some interface logic.
Control panel The control panel, which may be divided into the 'display' section and the 'control' section, allows the user, via firmware control, to interact with the microprocessor system by either exchanging information or by behaving as a DMA device. As a hardware monitor, the firmware console supplies the user with useful information about the microprocessor system by monitoring the contents of its address, data and c~ntrol buses. This information is displayed on the panel display section (16 address LEDs, 16 data LEDs and 8 status LEDs). The control section of the panel is used for entering the information transmitted to the microprocessor system. This information is generated either in the form of actual data or in the form of control signals. In the first case, the data is set (in binary representation) onto the 16 address/ data switches, before being transmitted through the system buses (as a DMA activity) or read-in by software resident in the microprocessor system (input device). In the Control Address
Data
Ii Interface logic
Data paths I Control Ioq ic
i Local buses
L..---16..-I
. . . . . .
Address I LEDs
I , LT o
"
16-.1[
~
.....
,6._..~ •
Data I LEDs IAdd/dotaswitches
0--
°
[DEV,NC W GO R
o o o # Status L ~ C o n t r o l Display
Control panel
~I '
#
• • switches
Control
Firmware console
Figure 4. User microprocessor system with firmware console attached
86
! ~System 'buses t
second case, the control signals are generated by eight control buttons/switches which are divided into two categories, namely 'memory access controls' and 'MPU controls'. Their individual functions are described below. Memory access controls
•
LOAD ADDRESS (LA pushbutton in Figure 4): the address set on the address/data switches is stored in the interface logic
•
ENABLE/DISABLE INCREMENT (INC switch): after each read/write operation the stored address is automatically incremented thus allowing access to successive memory locations • READ and WRITE (R and W pushbuttons): a system read/write operation is performed by the interface logic. The stored address is forced onto the bus while data is either read from the corresponding location or written into it. MPU controls
•
RESET (RS pushbutton): the firmware console and the microprocessor system are initialized and the MPU is forced to start execution at a predefined location • ENABLE/DISABLE DEVICE (DEV switch): when this switch is set to 'enable', the I/O console registers are enabled • GO (pushbutton): start execution at the address pointed by the program counter • SINGLE-STEP/RUN (S/R switch): when this switch is set to 'single' mode, the MPU will execute one cycle only and then halt. When set to 'run' the program is executed continuously.
Interface logic The interface logic (Figure 4) which supports the control panel consists of the 'data-paths' circuitry and the 'controllogic' circuitry. The aim of the data-paths circuitry is to interface the control panel to the MPU buses and is designed in such a way that the panel address/data switches and the display LEDs are presented to the rest of the system as a pair of addressable I/O registers. These two 8-bit registers, apart from implementing the I/O capabilities of the console, are also used to present a starting address to the MPU during a reset sequence. In addition to the I/O registers, a 16-bit address-pointer register is available for storing the address during DMA activities. Finally, the data-paths circuitry includes an address comparator for providing the hardware breakpoint facility (the address, where the MPU is to halt at, is preset onto the address/data panel switches). Since it is required to support more than one type of microprocessor, it is necessary for the console's control circuitry to be flexible in order to match the bus specifications of the various target microprocessor systems. This flexibility was provided by employing microprogramming in the following way: signals arriving from the MPU control bus and the control panel are used to initialize and control a number of different microroutines which form a 2 kbyte microprogram stored in EPROMs. Each microroutine consists of a sequence of microinstrucfions every one of which controls the console activities occuring within a particular
microprocessors
clock cycle. The microinstruction field contains the address of the next microinstruction as well as the information needed to control both the data-paths circuitry and the target MPU during that cycle.
Microprogram generation To support a new target microprocessor, a suitable microprogram is needed. Generating such a microprogram can be quite tedious if done by hand and is likely to contain faults. It is clearly desirable to have some method of automating this task, particularly if systems for several different host microprocessors are to be developed. By defining as a 'state' the status of conso[e output control signals within a clock cycle, the following method has been developed: the target MPU timing is first studied and a 'state diagram' (Mealy model) describing the functional operation of the console is constructed. The state diagram is then translated into groups of logic functions, which relate the control circuitry's input variables to the corresponding output control signals. A description of these functions together with some additional information about the position of the I/O signals with respect to the ROM address/data lines is entered as data to a program which has been written and runs on the main University computer. This program generates the microprogram in the form of paper tape for driving a PROM programmer.
Host software support The debugging facilities of inserting software breakpoints and accessing the MPU registers can only be implemented by writing some suitable software to be executed by the target MPU; these facilities are processor dependent. This software (approximately 300 bytes) is interrupt driven and interacts with the user via the control panel by receiving commands such as display/alter the microprocessor registers or set/clear software breakpoints. These commands are entered in coded form through the data switches of the panel, while the information returned by the program is displayed onto the data LEDs of the panel. The interrupt used to pass control to the above subroutine must be of the highest priority, e.g. the NMI input of the M6800. It should also be noted that an alternative way of providing the debugging facilities 1--4a of Table 1 is through using the above subroutine; that is under software control. The flexibility of the firmware console's control logic may be illustrated by its ability to be microprogrammed to generate such an interrupt at the end of each instruction cycle (as well as machine cycle for such MPUs as the Intel 8080). The firmware console, discussed in this second approach to the problem of providing a useful debugging aid, has been constructed and satisfactorily tested in conjunction with M6800 and Intel 8080 systems in the DSL. The required microprograms were generated using the technique described above.
CONCLUSIONS Both systems are expected to cater for the hardware/ software debugging requirements in the Digital Systems Laboratory and also for the rapidly increasing number of people outside the Laboratory who intend to utilize micro-
vol 2 no 2 april 78
processors in their own fields, and request advice from the DSL. The firmware console is less expensive than the softwarebased Bedbug system and is primarily intended for hardware or software development undertaken by hardware engineers. Furthermore, due to the flexibility of its microprogrammable interface, it may be applied to the majority of TTL-compatible microprocessors. The Bedbug system has the advantages of providing more sophisticated debugging facilities and more powerful information I/O and is therefore useful for microcomputer system engineers requiring primarily software supporting aids. However, in situations where the advantages of both debugging aids are required, the ability of each system to be plugged into the microprocessor system buses independently allows both systems to coexist in the microcomputer system under development. Further research may look at the possibility of combining the advantages of both debugging aids, that is flexibility and sophistication, into a more comprehensive tool catering for the future development of microprocessorbased digital systems. Ideally, future development along these lines should also cater for the use of high-level languages on microprocessors, for assembly-language programming and debugging is becoming a tedious and inefficient exercise as application specifications increase. Amongst other aids being investigated for debugging microprocessor systems is MicroAde, produced by CAP Microsoft v. This is available in the DSL and is currently being used to commission an M6800 system to control a model railway network.
ACKNOWLEDGEMENTS Swan Hunter Shipbuilders Limited, the Science Research Council, Mr MJ Elphick, Mr N Ghani, Mr IG Givens and Dr PC Treleaven are acknowledged for their assistance in making this work possible.
REFERENCES 1 Ghani, N and Givens, JG, 'A teaching laboratory for digital systems' Tech. Rep. 109, University of Newcastle Upon Tyne (July 1977) 2 Motorola M6800 system design manual Motorola (1975) 3 Ghani, N DSL M6800 user notes Computing Laboratory, University of Newcastle Upon Tyne (1976) 4 Farrell, EP Software based microcomputer development systems MSc thesis, University of Newcastle Upon Tyne (December 1977) S Kanellopoulos, NG An investigation into hardware, firm ware and software techniques for pro riding a generalised control pane/for a microprocessor system
MSc thesis, University of Newcastle Upon Tyne (to be submitted) 6 Harrison, KF Alphanumeric video display module BSc (Hons) thesis, University of Newcastle Upon Tyne (June 1977) 7 Userguide forMicroAde LevelA Release I CAP Microsoft (June 1977)
87
Current teaching and research activities at Newcastle University invo/ving microprocessor systems, have shown the need for debugging aids which can be used for efficiently tracking down both hardware and software faults during the deve/opment stage of microprocessor-based digital systems. The paper describes the implementation of two different approaches to this problem, the collective aim being to provide sophistication combined with flexibi/ity. In the DSL (Digital Systems Laboratory) at the University of Newcastle Upon Tyne, numerous projects, using microprocessors, are undertaken by students and research workers. Such projects have included logic testers, data-acquisition/ processing systems and floppy-disc control and management systems. The DSL's microprocessor systems are designed round a basic framework of wire-wrap card¢ holding components such as the MPU (microprocessing unit), peripheral control units and memory elements. This basic framework provides students with flexibility in constructing microprocessor-based digital systems on a general-purpose wiring chassis. The most commonly used microprocessor system in the DSL is the Motorola M6800 family 2. One of the standard modules is a hardware console 3 which was designed for the M6800 system to provide the facilities of memory read/ write access and single-step/go execution control, together with the ability to allow the user to initialize the MPU program counter to any selected value. As shown in Figure 1, this hardware console consists of a general-purpose control panel (based on lights, switches and pushbuttons) and a card holding the necessary logic to interface the panel to the M6800 buses. Software support is provided by the University's time-shared computing facility, based on an IBM 370/168, which gives students access to an M6800 crossassembler and simulator. TWO APPROACH
undertaken 4, s with the overall aim of investigating the implementation of the necessary debugging aids to locate both hardware and software bugs. The first approach is based on a monitor program which is executed by the host MPU and uses as its console an ASCII keyboard and an ordinary TV set. ]-his approach concentrated on providing the sophistication of facilities needed through software control under which user-program status information is continuously displayed on the TV screen; conceptually, the system may be described as a 'software console'. It was necessary to design some supporting hardware to preserve the integrity of the debugging software from corruption by the user's software. This aid was implemented on the M6800 framework described earlier. The second approach uses microprogramming techniques for interfacing the generalpurpose control panel, mentioned earlier, to the system buses of various MPUs (Motorola M6800, Intel 8080, Intersil 6100, etc.) and therefore concentrates on the flexibility of the design. The resulting 'firmware console' provides the same debugging facilities as the 'hardware console'. However if more sophisticated facilities are required, they can be implemented by adding some suitable software which is executed by the host MPU.
ES
To allow the microprocessor systems designed by the students to be debugged efficiently, it was decided that more sophisticated and flexible debugging aids were needed than the existing hardware console. Two projects have been Computing Laboratory, The University of Newcastle upon Tyne, Claremont Tower, Claremont Road, Newcastle upon Tyne NE1 7RU, UK
vol 2
no
2 april 78
Figure I. Hardware
console
83
APPROACH ONE
user program is being executed. The NMI control unit implements the following three functions
It is apparent that at present, due to the lack of powerful software debugging support systems, software development inevitably lags behind hardware development in microprocessor-based digital system design. With this in mind, the Bedbug debugging aid has been designed and is currently running on an M6800 system. Bedbug provides a powerful set of debugging facilities which are easy to use, and are briefly summarized as follows
• •
• • • • • • •
Loads the user program into memory Disassembles memory to check that the program has been loaded correctly Uses either symbols or absolute values to refer to addresses in memory Alters the contents of the user's microprocessor registers Either singlesteps or continuously executes the user program in conjunction with software breakpoints Carries out read/write memory accesses.
Bedbug organization Figure 2 shows a typical user microprocessor system to which Bedbug has been attached during system development. To the left of the dotted line is the user system consisting of an MPU, a memory area for user program/data storage and some I/O ports for user I/O handling; in many cases the user may also attach some special-purpose logic such as a floppydisc controlle~. To the right of the dotted line are the components forming the Bedbug system. The major part of Bedbug is the monitor program which is written in M6800 assembler and resides in 14kbytes of memory. This program implements the debugging facilities provided. The security of the monitor's memory is achieved by using the memory protection unit which is designed to stop the user program writing into the Bedbug memory and also to inform the monitor of such invalid memory write accesses. The interrupt control unit controls the NMI (nonmaskable interrupt) input of the host MPU such that NMI can only be activated when the I User microcomputersystem
'
J
I ports
Microprocessor address +
Bedbug developmentsystem
I program
I I protection I
I memory
I I unit
[11 1 data
I
+__ control buses
_ J
control unit
L=ll
I
h
/
" 1 '
Figure 2. User microprocessor system with Bedbug debugging system attached
84
The Bedbug console consists of two components. First, there is a keyboard, interfaced by an M6820 PIA (peripheral interface adaptor), which allows the user to enter commands and data. Second, there is the output side of the console, a conventional monochrome TV set which is interfaced to the system buses via an alphanumeric video display module 6. This module causes the contents of a 960 byte display memory to be continuously displayed as an image on the screen, using DMA (direct memory access). The module allows the image on the screen to be updated extremely rapidly when any part of display memory has been edited by the Bedbug monitor program. The 24 line by 40 character width display is split into a lower sixline scrolled block for user-Bedbug dialogue, while the upper 18-line section is used by each debugging facility's command subprogram for displaying various types of user program status information. The Bedbug serial output port consists of an M6850 ACIA (asynchronous communications interface adaptor). A hard-copy terminal can be connected to this serial port to obtain a hard copy of the current TV screen image. The final component in the Bedbug system is the paper-tape reader input port which consists of the other half of the keyboard PIA and allows the user object program to be loaded into memory. Bedbug provides 21 commands for the user, each distinguished by a single alphabetical character. The commands fall into three classes • • •
(a) Symbol and breakpoint table management (b) Memory and register access (c) Instruction execution control.
I
I Jinterface ] interface J J video-displayJJinterfaceJ
1
It supports user NMI interrupt handling It allows the user to interrupt his program manually, retain its full status and return control to Bedbug. This is in contrast to the basic RESET function normally provided by simple aids such as Mikbug, which do not stack the user's MPU registers It allows Bedbug to be informed of an invalid memory write access by the user.
Symbols and breakpoints Class (a) commands manage the Bedbug system symbol and breakpoint tables. Commands are provided for symbol/ breakpoint entry or release and also for listing the tables. The symbol table allows the user to make symbolic references to program variables, as he would in his assemblylanguage program, in addition to absolute address references. The breakpoint table enables the user to define multiple software breakpoint addresses; the two techniques used to implement software breakpoints will be described later. A future development will allow a symbol table to be loaded at the same time as the user object code; however, this will require the crossassembler to be modified.
Memory and registers Various class (b) commands are available to enable the user
microprocessors
to access the MPU registers and memory which are used by his program. These include • List memory blocks in hexadecimal format • Write hexadecimal values into memory locations • Disassemble memory to display it in a similar fashion to the assembly-language listing • Enter single machine instructions into memory in assembler format • Display/alter the contents of the user's MPU registers Tl~e disassemble and assemble commands are performed using special instruction information tables holding M6800 assembler information such as instruction size, addressing modes and mnemonic representation. The display/alter register command is implemented by accessing the snapshot of the user MPU registers which is always available on the stack. Finally, all class (b) commands allow symbols to be used in reference to addresses.
IEC (instruction execution control) Class (c) I EC commands allow the user to control program execution in two ways, referred to as 'in-mode' and 'outof-mode'. In-mode IEC causes control to be passed back to the monitor after each user program instruction is executed. This allows the UPSD (user program status display), as shown in Figure 3, to be continually updated. Out-ofmode IEC permits continuous execution of the program without continually updating the UPSD. Both of these modes support user hardware interrupt handling on the IRQ and NMI inputs of the M6800. Program execution may be suspended upon the following occurrences • • • •
Reaching a breakpoint A user invalid memory write access Manually interrupting the user program by pressing a key on the console keyboard A selected memory location changing value (memory trap), this applies to in-mode IEC only
The scheme for switching the MPU between the monitor and user programs uses the instructions, SWI (software interrupt) and RTI (return from interrupt), to push and pop a snapshot of the user register contents to and from the stack. With in-mode IEC the monitor places a SWI trap in the user program at the address of the successor to the next instruction to be executed. It then executes an RTI to reload the register snapshot into the MPU. This causes the next user instruction to be executed, after which the trap is executed causing the new register snapshot to be stacked. On regaining control, the monitor then updates the UPSD and checks for a possible suspension of program execution. Of course, certain instructions require more than one trap to be planted into the user code. However, by using an instruction information table, the monitor can handle special cases such as conditional branch instructions. The memory trap location is monitored by checking the current value of the selected location against the original value it held at the time the user defined the memory-trap address. Finally, in this mode software breakpoints are implemented
vol 2 no 2 april 78
by checking the address of the next user instruction against the current contents of the breakpoint table. In the case of out-of-mode IEC, control is passed directly back to the user program by executing RTI without inserting traps, apart from those which implement software breakpoints. Control is then only returned to the monitor if any of the first three occurrences listed above take place. In conclusion, it is interesting to consider the main problem in implementing Bedbug on other microprocessors. This problem concerns class (c) IEC commands; in principle these are the only ones to be machine dependent. Careful I EC algorithm definition is required to take account of certain machine dependent factors, particularly the interrupt architecture of the MPU. However, such careful definition should allow Bedbug to be implemented on the majority of currently available microprocessors.
SECOND APPROACH Microprocessor manufacturers provide many different types of debugging consoles, offering to the user the ability to interact with his system. However, the majority of these consoles are dedicated to a particular microprocessor product and the user buying such a debugging console is limited to using the corresponding MPU. This limitation is strongly felt in teaching environments, such as the DSL, where different MPUs are frequently employed. What is really needed, therefore, is to investigate the possibility of providing a processor-independent console. This section describes the 'firmware console', an attempt to provide a processor-independent debugging console, utilizing the general-purpose 'control panel' mentioned above. The main innovation is the use of microprogramming techniques to provide the design with the required flexibility. The debugging capabilities of the firmware console are indicated in Table 1. The firmware console may be viewed by a microcomputer system as a peripheral device, which may be used as • a hardware monitor • an I/O device • a controlling device of highest priority
Figure 3. User program status disp/ay
85
Table 1. Debugging facilities of the firmware console • • • • •
(1) Addresses successive memory locations, verifying or changing their content (2) Forces the MPU to start execution from a specified location (3) Controls the processor thus allowing continuous program execution or single instruction execution (4) Traces program execution inserting (a) hardware breakpoints or (b) software breakpoints (5) Displays/alters MPU registers
Figure 4 illustrates the firmware console connected to a user MPU system via the system buses. It consists of two parts, namely the general-purpose control panel (shown also in Figure 1) and some interface logic.
Control panel The control panel, which may be divided into the 'display' section and the 'control' section, allows the user, via firmware control, to interact with the microprocessor system by either exchanging information or by behaving as a DMA device. As a hardware monitor, the firmware console supplies the user with useful information about the microprocessor system by monitoring the contents of its address, data and c~ntrol buses. This information is displayed on the panel display section (16 address LEDs, 16 data LEDs and 8 status LEDs). The control section of the panel is used for entering the information transmitted to the microprocessor system. This information is generated either in the form of actual data or in the form of control signals. In the first case, the data is set (in binary representation) onto the 16 address/ data switches, before being transmitted through the system buses (as a DMA activity) or read-in by software resident in the microprocessor system (input device). In the Control Address
Data
Ii Interface logic
Data paths I Control Ioq ic
i Local buses
L..---16..-I
. . . . . .
Address I LEDs
I , LT o
"
16-.1[
~
.....
,6._..~ •
Data I LEDs IAdd/dotaswitches
0--
°
[DEV,NC W GO R
o o o # Status L ~ C o n t r o l Display
Control panel
~I '
#
• • switches
Control
Firmware console
Figure 4. User microprocessor system with firmware console attached
86
! ~System 'buses t
second case, the control signals are generated by eight control buttons/switches which are divided into two categories, namely 'memory access controls' and 'MPU controls'. Their individual functions are described below. Memory access controls
•
LOAD ADDRESS (LA pushbutton in Figure 4): the address set on the address/data switches is stored in the interface logic
•
ENABLE/DISABLE INCREMENT (INC switch): after each read/write operation the stored address is automatically incremented thus allowing access to successive memory locations • READ and WRITE (R and W pushbuttons): a system read/write operation is performed by the interface logic. The stored address is forced onto the bus while data is either read from the corresponding location or written into it. MPU controls
•
RESET (RS pushbutton): the firmware console and the microprocessor system are initialized and the MPU is forced to start execution at a predefined location • ENABLE/DISABLE DEVICE (DEV switch): when this switch is set to 'enable', the I/O console registers are enabled • GO (pushbutton): start execution at the address pointed by the program counter • SINGLE-STEP/RUN (S/R switch): when this switch is set to 'single' mode, the MPU will execute one cycle only and then halt. When set to 'run' the program is executed continuously.
Interface logic The interface logic (Figure 4) which supports the control panel consists of the 'data-paths' circuitry and the 'controllogic' circuitry. The aim of the data-paths circuitry is to interface the control panel to the MPU buses and is designed in such a way that the panel address/data switches and the display LEDs are presented to the rest of the system as a pair of addressable I/O registers. These two 8-bit registers, apart from implementing the I/O capabilities of the console, are also used to present a starting address to the MPU during a reset sequence. In addition to the I/O registers, a 16-bit address-pointer register is available for storing the address during DMA activities. Finally, the data-paths circuitry includes an address comparator for providing the hardware breakpoint facility (the address, where the MPU is to halt at, is preset onto the address/data panel switches). Since it is required to support more than one type of microprocessor, it is necessary for the console's control circuitry to be flexible in order to match the bus specifications of the various target microprocessor systems. This flexibility was provided by employing microprogramming in the following way: signals arriving from the MPU control bus and the control panel are used to initialize and control a number of different microroutines which form a 2 kbyte microprogram stored in EPROMs. Each microroutine consists of a sequence of microinstrucfions every one of which controls the console activities occuring within a particular
microprocessors
clock cycle. The microinstruction field contains the address of the next microinstruction as well as the information needed to control both the data-paths circuitry and the target MPU during that cycle.
Microprogram generation To support a new target microprocessor, a suitable microprogram is needed. Generating such a microprogram can be quite tedious if done by hand and is likely to contain faults. It is clearly desirable to have some method of automating this task, particularly if systems for several different host microprocessors are to be developed. By defining as a 'state' the status of conso[e output control signals within a clock cycle, the following method has been developed: the target MPU timing is first studied and a 'state diagram' (Mealy model) describing the functional operation of the console is constructed. The state diagram is then translated into groups of logic functions, which relate the control circuitry's input variables to the corresponding output control signals. A description of these functions together with some additional information about the position of the I/O signals with respect to the ROM address/data lines is entered as data to a program which has been written and runs on the main University computer. This program generates the microprogram in the form of paper tape for driving a PROM programmer.
Host software support The debugging facilities of inserting software breakpoints and accessing the MPU registers can only be implemented by writing some suitable software to be executed by the target MPU; these facilities are processor dependent. This software (approximately 300 bytes) is interrupt driven and interacts with the user via the control panel by receiving commands such as display/alter the microprocessor registers or set/clear software breakpoints. These commands are entered in coded form through the data switches of the panel, while the information returned by the program is displayed onto the data LEDs of the panel. The interrupt used to pass control to the above subroutine must be of the highest priority, e.g. the NMI input of the M6800. It should also be noted that an alternative way of providing the debugging facilities 1--4a of Table 1 is through using the above subroutine; that is under software control. The flexibility of the firmware console's control logic may be illustrated by its ability to be microprogrammed to generate such an interrupt at the end of each instruction cycle (as well as machine cycle for such MPUs as the Intel 8080). The firmware console, discussed in this second approach to the problem of providing a useful debugging aid, has been constructed and satisfactorily tested in conjunction with M6800 and Intel 8080 systems in the DSL. The required microprograms were generated using the technique described above.
CONCLUSIONS Both systems are expected to cater for the hardware/ software debugging requirements in the Digital Systems Laboratory and also for the rapidly increasing number of people outside the Laboratory who intend to utilize micro-
vol 2 no 2 april 78
processors in their own fields, and request advice from the DSL. The firmware console is less expensive than the softwarebased Bedbug system and is primarily intended for hardware or software development undertaken by hardware engineers. Furthermore, due to the flexibility of its microprogrammable interface, it may be applied to the majority of TTL-compatible microprocessors. The Bedbug system has the advantages of providing more sophisticated debugging facilities and more powerful information I/O and is therefore useful for microcomputer system engineers requiring primarily software supporting aids. However, in situations where the advantages of both debugging aids are required, the ability of each system to be plugged into the microprocessor system buses independently allows both systems to coexist in the microcomputer system under development. Further research may look at the possibility of combining the advantages of both debugging aids, that is flexibility and sophistication, into a more comprehensive tool catering for the future development of microprocessorbased digital systems. Ideally, future development along these lines should also cater for the use of high-level languages on microprocessors, for assembly-language programming and debugging is becoming a tedious and inefficient exercise as application specifications increase. Amongst other aids being investigated for debugging microprocessor systems is MicroAde, produced by CAP Microsoft v. This is available in the DSL and is currently being used to commission an M6800 system to control a model railway network.
ACKNOWLEDGEMENTS Swan Hunter Shipbuilders Limited, the Science Research Council, Mr MJ Elphick, Mr N Ghani, Mr IG Givens and Dr PC Treleaven are acknowledged for their assistance in making this work possible.
REFERENCES 1 Ghani, N and Givens, JG, 'A teaching laboratory for digital systems' Tech. Rep. 109, University of Newcastle Upon Tyne (July 1977) 2 Motorola M6800 system design manual Motorola (1975) 3 Ghani, N DSL M6800 user notes Computing Laboratory, University of Newcastle Upon Tyne (1976) 4 Farrell, EP Software based microcomputer development systems MSc thesis, University of Newcastle Upon Tyne (December 1977) S Kanellopoulos, NG An investigation into hardware, firm ware and software techniques for pro riding a generalised control pane/for a microprocessor system
MSc thesis, University of Newcastle Upon Tyne (to be submitted) 6 Harrison, KF Alphanumeric video display module BSc (Hons) thesis, University of Newcastle Upon Tyne (June 1977) 7 Userguide forMicroAde LevelA Release I CAP Microsoft (June 1977)
87