lab 2: 80x86 interrupts
TRANSCRIPT
ELEC-4601: Microprocessor Systems
Lab 2: 80x86 Interrupts The Point Writing software to properly respond to a hardware interrupt is fussy. There is a hardware path from the
incoming interrupt signal all the way to the microprocessor that needs to be correctly laid out and ‘enabled’ using
specific bits within specific registers that are located at specific addresses in the I/O mapped memory space of the
microprocessor. In this lab, the microprocessor is a member of the 80x86 family but the process or laying out and
enabling this path is fundamentally the same for all microprocessors and microcontrollers.
There are typically three places where interrupts can be enabled or disabled i.e. allowed to proceed or blocked
from proceeding. The microprocessor itself usually has a global ‘Interrupt enable’ bit or bits as part of a CPU flags
register e.g. IF bit in the FLAGS register in the 80x86. If there is a subsystem that is responsible for arbitrating incoming
interrupts (in this case, the 8259 Programmable Interrupt Controller or PIC) then it will have registers and bits that need
configuring to accept an interrupt and forward it on to the CPU. Finally, the interface subsystem that actually connects
to the interrupt source will have some set of registers and bits that need to be configured in order to let the interrupt
proceed on its way to the interrupt arbitrator (e.g. the PIC).
Once the hardware path has been properly enabled and interrupts can actually reach the CPU, the software has to be
written to recognize the interrupt, service it, and gracefully restore the system back to its normal ‘waiting for an interrupt’
state.
The frustrating part of this process arises from the fact that unless everything is working and configured properly
then the system will fail, usually in a fatal fashion. If all the hardware isn’t configured properly you will not see the
interrupt. Once you can see the interrupt, incorrect software will fail (totally) and you will have to reset the hardware
and try again. Debugging a hardware interrupt in real time is a notoriously difficult thing but once you have done it for a
system such as this one you will know what to look for in any microprocessor system and you will be able to anticipate
the amount of time to allocate to this part of the design process. This is something worth knowing.
Introduction
Interrupts offer an alternate way of responding to external events in a microprocessor system. The microprocessor
can ‘poll’ for changes in the environment by constantly looking for those changes or it can wait until a device signals a
change and ‘handle the interrupt’ caused by the change. For real time events, such as keyboard presses, internal time-of-
day clock changes, printer-out-of-paper etc., an actual hardware digital signal, referred to as an IRQ (Interrupt ReQuest)
can be generated. They are usually numbered according to their priority, with IRQ0 having the highest priority (the system
time-of-day) and IRQ7 the lowest (the LPT1 printer port). For typical simple microprocessor systems, the following
flowchart applies:
The software procedure, usually small and fast, that runs in response to an interrupt is referred to as an Interrupt
Service Routine (ISR). 80X86 processors operating in real-mode (the simple microprocessor mode used in the lab) make
use of an Interrupt Descriptor Table (IDT) which consists of 256 entries (numbered 0 through 255), each of which holds
the address of an ISR. The IDT starts at memory location 0000:0000. Most of these entries are for the 255 ‘software’
interrupts and processor exceptions that the processor supports. Some of the entries in this table have been set aside for
‘hardware’ interrupts, with IRQ0 to IRQ7 using up the IDT slots at positions 8 to 15, and IRQ8 to IRQ15 using up the IDT
slots at positions 0x70 to 0x77. In response to an interrupt, the processor will finish executing the current instruction,
immediately jump to the address stored in the IDT at the appropriate location, and continue executing instructions from
this new address.
Purpose
This lab will investigate a number of things in software:
- the steps necessary to get a typical microprocessor system to actually recognize that an external hardware
interrupt has occurred
- the steps necessary to service this interrupt and to clear the interrupting condition
This lab will look at a number of things related to hardware:
How to debug interrupts using the logic analyzer
How to measure the speed of interrupt handlers
Execute software instruction
Save state, jump to service
Service the interrupt
Restore state as before interrupt
Interrupt received?
YES
No
Equipment required
HP 16702B Logic Analyzer
PC/104 or ISA bus PC
HP33120A Function Generator for Part A
Windows PC with a serial port and running a terminal (TeraTerm Pro) program
Part A : Simple Squarewave Interrupts
This portion of the lab concerns setting up a simple square wave generator to input a TTL signal at a variable frequency
through the IRQ7 hardware interrupt of a conventional 80x86 PC. In addition, the lab involves writing software to allow
this interrupt to be recognized by the 80x86 processor and to display a count of the interrupts that have been recognized.
The student is expected to have tried to fill in the steps of the LAB2A.PAS text file that has been posted to the course
website. The steps are laid out in the source file with the actual setting/clearing of register bits, as required, left to the
student. All registers of interest for the purposes of this lab are I/O mapped i.e. the bits within each register can be
accessed through the standard instructions
MOV DX,<register address>
IN AL,DX ; read an 8-bit device register value whose I/O address is <register address>
OR AL,<some value> ; set one or more bits in the register
AND AL,<some value> ; clear one or more bits in the register OUT
DX,AL ; write an 8-bit value back to the device register
The registers of interest are documented in Appendix C at the end of this lab.
Procedure
1 . Fill in the necessary code in the LAB2A.PAS file that has been supplied. This is most of the work.
2. Create an executable (.EXE) file from this code using the supplied tools (MAKE.BAT, TPC.EXE, TURBO.TPL) e.g.
C>make lab2a.pas
3. Run the LAB2A.EXE file
4. Turn on the HP33120 function generator and set it for a squarewave at about 100Hz. Connect the SYNC output of this
function generator, using a supplied BNC cable, to the little black parallel port unit with the LED lights on it (there
should be a BNC connector on the end of this unit).
4. Observe the results, which should be the following
- the 8 bit LED display should show an incrementing binary count
- the LED display should count faster or slower as the frequency of the squarewave generator is increased or
decreased
5. Measure the response time of the software. The response time will be defined as the time difference between the
rising edge of the IRQ7 interrupt signal (the squarewave) and the final execution of the code that is in the Interrupt
Service Routine. The logic analyzer will be required in order to make this measurement.
Performing time measurements on an interrupt driven system is sometimes tricky and you generally have to include your
own ‘markers’ (unique events that simplify triggering o f the logic analyzer) into the code. This code is removed after you
have done the tests that you want to do. A recommended event, immediately after you enter the ISR and save your
registers (notice that saving the DX register is now required because of this code) is the following : MOV DX,0379h ; read
the parallel port status, something unique
IN AL,DX
It is pretty much a certainty for this lab that you have the following code inside your ISR in some fashion, just before you
exit the ISR (hint here)
OUT 020h,020h ; send EOI to PIC and enable further interrupt processing
Unfortunately, this particular instruction is being executed all the time in a normal, simple PC system when other
interrupts, such as the system timer that keeps track of the time of day, are being handled. So a more unique condition
for our test would be to trigger on the two instructions: an I/O read from address 0379h followed by an I/O write to
address 020h. If you trigger on this event, a display on the logic analyzer of the IRQ7 rising edge, followed by the I/O read
and write, will give you a single picture from which you can make a timing measurement.
Measure the time from the IRQ7 rising edge to the execution of the ‘marker’ instruction above. This is the ‘interrupt
response time’ to get to the first part of your ISR. Knowing that the processor that we are using is a 40MHz 80386sx, and
knowing how many instructions are executed before executing the ‘marker’ (basically a few PUSH instructions), calculate
a more accurate value for the response time i.e. what you measured minus the time it takes to save some things on the
stack.
Now measure the time it takes to actually service the interrupt i.e. the time from the very first instruction of the ISR to the
very last. This is just the time that elapses between the ‘marker’ command and the ‘write EOI to PIC’ command. Now adjust
this time to account for the code that occurs just before the marker (the PUSH commands) and the code that occurs just
after the EOI write (the POP commands and the IRET).
6. Show the TA that you have made the measurements (two screen shots of the logic analyzer should be taken) and that
the little LEDs on the parallel port actually operate as expected.
Note:
Load your LAB1 configuration file for the Logic Analyzer. This time, you will need to add the IRQ, IOR and IOW pins to
your configuration. Refer back to Lab 1’s setup procedure, if you need more help. Refer to Appendix B for the pin layout.
**Note: IOR and IOW are located on the clock inputs. **
Part B : Serial Port Interrupts
This portion of the lab involves generating an interrupt by sending one or more serial characters over a connection
between the Windows PC at the lab station and the 80x86 microprocessor that we are testing. For the setup that we are
using, the hardware interrupt of interest is IRQ4 (serial port COM1 in a PC).
In addition, this lab involves writing software to handle this interrupt and to echo the received characters back to the
Windows PC over the serial connection. The software for this part of the lab is almost exactly the same as the previous
code, except for some setup of the serial communications chip and the use of a different IRQ signal.
Procedure 1
Make sure that you have TeraTerm Pro running on the Windows machine at your workstation and that is is setup as
shown in Appendix D. Run the ‘mode’ command on the 80x86 system as described in the appendix.
First, a quick check of the connection between the two machines. Run ‘debug; on the 80x86 machine as you did in Lab 1.
C>debug
-
Now press the ‘A’ key on the Windows machine keyboard while the TeraTerm Pro app has the focus. Then look at the
contents of the register at i/o address 0x3F8
- i 3F8
61
Hex 61 is the ASCII (a standard for encoding serial data) code for the lowercase letter ‘a’. Repeat this process (press key,
read port 0x3F8) for the letters ‘b’,’c’ and’d’ and note the codes.
Now look at the contents of the registers at 0x3F9 (IMR) and 0x3FA (IIR)
- i 3F9
00
- i 3FA
01
From the register information, this shows that no interrupts are enabled and no interrupts are pending. Now enable the
interrupt that occurs when a character is available from the serial port:
- o 3F9 01
Now press the ‘a’ key on the Windows keyboard and then read the register at 0x3FA
- i 3FA
04
This indicates that an interrupt has been generated and that the interrupt is related to the ‘Received Data Available
Interrupt’. Read the value of port 0x3FA several times to show that the interrupt is still pending (the value doesn’t
change).
Now read the value at port 0x3F8 and then the value at port 0x3FA
- i 3F8
61
- i 3FA
01
This indicates that the act of reading the serial buffer register automatically clears the interrupt condition i.e. you have
‘handled the interrupt’
Procedure 2
Now make and run the LAB2B.PAS code that you have written for the lab.
Proper operation is indicated by a simple echoing of the character pressed at the Windows keyboard i.e. if you press the
‘a’ key, you will see an ‘a’ appear in the window.
Hopefully we will have a little demonstration station setup so that you can actually see the serial communication
waveforms on an oscilloscope and see how they change with the data and with changes to the communication
parameters.
Write up and Deliverables: 1. Parallel Port Interrupt
a. Print and submit well commented code for both of the interrupts.
b. Have a TA check and verify that your parallel port interrupt counter works from the 1 to 100Hz range.
c. Using your logic analyzer, monitor the IRQ, IOR, IOW and the ADDR lines. Track the changes in the
address lines. How long does it take from receiving the interrupt to the code jump? Print out a screenshot
and hand it in.
d. Speed up the incoming clock, and see if you can make the ISR fail. How might it fail?
2. Serial Interrupt
a. Demonstrate the serial interrupt echo.
Appendix A
PIC# (Base
Address) INT (Hex) IRQ Common Uses
00 - 01 Exception Handlers -
02 Non-Maskable IRQ Non-Maskable IRQ (Parity Errors)
03 - 07 Exception Handlers -
PIC#1 (0x20) 08 Hardware IRQ0 System Timer
09 Hardware IRQ1 Keyboard
0A Hardware IRQ2 Redirected
0B Hardware IRQ3 Serial Comms. COM2/COM4
0C Hardware IRQ4 Serial Comms. COM1/COM3
0D Hardware IRQ5 Reserved/Sound Card
0E Hardware IRQ6 Floppy Disk Controller
0F Hardware IRQ7 Parallel Comms.
10 - 6F Software Interrupts -
PIC#2 (0xA0) 70 Hardware IRQ8 Real Time Clock
71 Hardware IRQ9 Redirected IRQ2
72 Hardware IRQ10 Reserved
73 Hardware IRQ11 Reserved
74 Hardware IRQ12 PS/2 Mouse
75 Hardware IRQ13 Math's Co-Processor
76 Hardware IRQ14 Hard Disk Drive
77 Hardware IRQ15 Reserved
78 - FF Software Interrupts -
Table 1 : x86 Interrupt Vectors
Appendix B Channel Number
[Pin #] POD 1 POD 2 POD 3
Pin Name
DATA Pin Name
ADDR Pin Name
MISC
GND GND GND GND 0 SD0 SA0 SA16 1 SD1 SA1 SA17 2 SD2 SA2 SA18 3 SD3 SA3 SA19 4 SD4 SA4 IRQ4 5 SD5 SA5 IRQ5 6 SD6 SA6 IRQ3 7 SD7 SA7 IRQ7 8 SD8 SA8 MEMR 9 SD9 SA9 MEMW
10 SD10 SA10 BALE 11 SD11 SA11 REFRESH 12 SD12 SA12 AEN 13 SD13 SA13 OSC 14 SD14 SA14 SYSCLK 15 SD15 SA15 - CLK IOR IOW
Table 2: Logic Analyzer Pin Assignments
Appendix C (also available as a separate document) Links : http://retired.beyondlogic.org/serial/serial.htm http://retired.beyondlogic.org/spp/parallel.htm
Dir = direction, R=read, W=write, R/W=read and write
Register offset : add this to the base I/O address to access the register itself
Device Base address Register
offset
Dir Bit functions
PIC
0x20
0 W Command
1
R/W
IMR Interrupt Mask Register
7 6 5 4 3 2 0
for IRQn, n=0..7
Bit n = 0, interrupt IRQn enabled
Bit n = 1, interrupt IRQn disabled
LPT1 0x378 0 W data port
a read returns the last byte
written
1 R status port
2 R/W control port
7 5 4 3 2 1 0
7..6 : unused
5 : enable bi-directional port
4 : enable IRQ through the pin 10
3 : select printer
2 : reset printer
1 : auto linefeed
0 : strobe
Device Base address Register
offset
Dir Bit functions
COM1
0x3F8
0 R/W Data register
Read receiver data
Write transmitter data
0
R/W Baud rate divisor low
if DLAB bit=1 in LCR below
low byte of 16-bit baud rate
divisor
1
R/W
IER
Interrupt Enable Register
7 6 5 4 3 2 1 0
enable=1, disable=0
7..4 : reserved
3 : enable modem status int.
2 : enable receiver line status int.
1 : enable transmitter empty int.
0 : enable receiver full int.
1 R/W Baud rate divisor high
if DLAB bit=1 in LCR below
high byte of 16-bit baud rate
divisor
2 R IIR
Interrupt Identification Register
Device Base address Register
offset
Dir Bit functions
COM1 0x3F8 3 R/W LCR
Line Control Register
7 6 5 4 3 2 1 0
7 : DLAB=0 normally
: DLAB=1 to access baud rate
divisor bytes
6 : set break enable if 1
5..3 : parity select code
X X 0 no parity
0 0 1 odd parity
0 1 1 even parity
1 0 1 parity bit always high
1 1 1 parity bit
always low
2 : one stop bit =
0 two stop bits = 1
1..0 : word length
1 1 = eight bit data
1 0 = seven bit data
0 1 = six bit data
0 0 = five bit data
4 R/W MCR Modem Control Register
5 R/W LSR Line Status Register
Table of Baud Rate Divisor Values for a serial port Values
based on the following calculation : divisor = 1843200/16/baud_rate
e.g. for 2400 baud rate, divisor = 1843200/16/2400 = 49 (decimal) = 0x30
bps (bit/sec) divisor (decimal) latch high byte (hex) latch low byte (hex)
50 2304 09h 00h
300 384 01h 80h
600 192 00h C0h
2400 48 00h 30h
4800 24 00h 18h
9600 12 00h 0Ch
19200 6 00h 06h
38400 3 00h 03h
57600 2 00h 02h
115200 1 00h 01h
Appendix D
Running TeraTerm Pro on the Windows machine in the lab.
Somewhere on the desktop of the Windows machine at the lab station will be an icon for the serial terminal program
TeraTerm Pro. HyperTerminal is the classic terminal program for windows but it doesn’t normally come with Windows 7
(the version in the lab). Start up this program and you should get an option for either a ‘TCP/IP’ connection or ‘serial’
connection. Choose the serial connection over COM1 (the communication port in the Windows machine). A window
should appear that looks like the the following:
a
Serial communication connections have setup information that you need to configure. You can get at this information
through the main menu:
Selecting the ‘Serial port…’ option will finally bring up the place where communications parameters can be changed:
For this lab, these default settings are fine.
For communication to the 80x86 system to work, we need to ensure that the 80x86 system is physically connected to
the Windows 7 with a serial cable. The cable is what is referred to as ‘DB-9’ . The ‘DB’ specifies the shape and style of the
connectors on the end of the cable (a letter ‘D’ rectangular shape) and the 9 specifies the number of pins on the
connector. You should also see the words ‘NULL’ or ‘NULL MODEM’ on the cable. This ensures that the pins used to
transmit and receive data are connected properly between the machines i.e. the transmitted data from one machine is
connected to the received data of the other and vice versa.
Ensure that the serial cable is connected to the Serial1 connector on the 80x86 machine. This is also referred to as
COM1:
Now ensure that the serial communication parameters on the 80x86 system are the same as the Windows machine.
From a command prompt on the 80x86 system, type the following:
C>mode com1: 9600,n,8,1
This will execute the ‘MODE’ command on the port ‘COM1’ (the one connected to the Windows machine) and set the
parameters for 9600 baud, no parity, 8 data bits, 1 stop bit. This should match the Windows machine and now serial
communication should be possible.