EXPERIMENT NUMBER 5 Creating a Single Chip Memory Space for the 8051

Size: px

Start display at page:

Download "EXPERIMENT NUMBER 5 Creating a Single Chip Memory Space for the 8051"

Pearl Parsons
6 years ago
Views:

1 5-1 EXPERIMENT NUMBER 5 Creating a Single Chip Memory Space for the 8051 INTRODUCTION: The 8031 microcontroller on the XS40 board is an 8051-type microcontroller, but unlike the 8051 it contains no on-chip ROM. All code must be stored external to the chip. On the XS40 board, all code and data is stored in a single 32KB SRAM. In this lab you will learn to partition the single SRAM into memory space for both code and data. You will write an assembly program that partitions space for data, while also reserving space for code. Your program will display a message of your choosing on the seven-segment display of the XS40 board, using your hardware design from lab 4. This message will be stored in a table in external memory. OBJECTIVES: 1. Create a shared memory space with assembly directives and special-purpose hardware. 2. Use Keil software development tools to test a microcontroller program. 3. Use a hardware graphical user interface (GUI) to debug your design in a cosimulation environment. 4. Show possible shortcomings of testing only the software portion of a hardware-software design, without the hardware portion. 5. Reinforce concepts of cosimulation. REFERENCES: Appendix D, XS40 Schematic: Tutorial for µvision 2: Report: Defining the location of memory: MATERIALS REQUIRED: 1. Keil µvision 2 2. Windows-based computer with an unused parallel port 3. Unix-based computer 4. Mentor Graphics software: Design architect and Quicksim Pro 5. XS40 prototyping board 6. Ftp program BACKGROUND: Figure 1 shows the standard configuration of an 8051 with external memory.

2 EPROM P0 ALE P2 PSEN/ RD/ WR/ LATCH Q Q D D0-D7 A0-A7 A8-A15 OE/ SRAM D0-D7 A0-A7 A8-A15 RD/ WR/ Figure with separate code and data space Code and data space are separated by the separate chips and by the control signals PSEN/, RD/, and WR/. The ROM (code space) is activated by PSEN/, which only goes low when reading code. The RAM (data space) is activated by RD/ and WR/, which only go low when reading/writing data. For the XS40 board, however, code and data space share the same chip, a 32K block of SRAM. The RAM chip is read from when either RD/ or PSEN/ goes low and is written to when WR/ goes low. The hardware required to SRAM PSEN/ RD/ WR/ OE/ WE/ Address Space 0x0000 0x2048 Code Segment 0x5280 0x6000 Data Segment 0xAA55 Memory Mapped Port Figure 2 Unified code and data space

3 5-3 combine these control signals is illustrated in Figure 2. The schematic you used for lab 4 should work fine. The trick, then, is to write a program that keeps your data and code in separate locations within this chip. Instead of code and data being stored in separate chips as in Figure 1, they are stored at separate addresses as shown in Figure 2. Notice that location AA55H has been labeled as the memory mapped port which controls the seven-segment display. In the assembly language, memory is partitioned into segments. Each segment can be used to store code or data or to define addresses for external hardware. These segments are defined to be either absolute or relocatable. A relocatable segment can be relocated by the linker. That is, the linker decides where the segment should be located in memory. The location of an absolute segment is set by the programmer ( the segment absolutely goes here ). To put code and data on the same chip, we need to control the use of memory very carefully, because a code segment cannot be located at the same address as a data segment. To control exactly where the code and data segments will be placed in memory, we will be using absolute code and data segments. An absolute external data segment (a segment of data located in external memory) is created with the assembler directive XSEG. The line of code with the XSEG directive is followed by the definition of variables we wish to place within the external segment. A variable can be created using the DS (Define Storage) directive. For example, a 1-byte variable called temp can be created and located at location 0x5280 in external memory using the commands: XSEG AT 5280H ; begin an external data segment at address 5280H temp: DS 1 ; declare a 1-byte variable, temp, within the XSEG The AT 5280H places the segment at location 0x5280. The variable temp is the first variable within that segment. More accurately, temp is a label to a location in memory, in this case, to location 5280H. The linker will replace the word temp with 5280H wherever it occurs within your code. For example, the command MOV DPTR, #temp would be changed to MOV DPTR,#5280H. An absolute code segment is defined in much the same way as an external data segment. To define an absolute code segment at 0x0000, use the command: CSEG AT 0000H ; begin a code segment at address 0000H <assembly instructions> Your assembly code would immediately follow the CSEG command as shown. Remember, everything that follows a segment directive is included in that segment.

4 5-4 PRELIMINARY: For the preliminary assignment, write an assembly program which sends a message to the seven-segment display. Your program should contain three segments: a code segment starting at 0x0000, an external data segment starting at 0x5000, and an other external data segment located at 0xAA55. The segment at 0xAA55 will contain a variable which points to the seven-segment display. Any value you write to this variable will also be written to the seven-segment display. This variable should be 1-byte in size (e.g. sevenseg: DS 1). The segment starting at 0x5000 will contain the message you will write to the sevensegment display. This message is stored as a table of hex values which represent characters on the display (See Table 1). Define the size of this table equal to the size of your message using the DS directive. Initialize message table Retrieve character from table Write character to seven-segment display Short delay Next character Figure 3: Program flowchart The basic functions of the program you need to write are outlined in the flowchart in Figure 3. The first thing your assembly program should do is copy your message to data memory. To generate the hex values for each character, think about which LEDs on the seven-segment display need to be lit to display that character. Table 1 gives some suggestions. Note that not all these characters are obvious on the display. Your program should then continuously loop through your message table copying the values to the seven-segment display. You may wish to add a delay inside the loop, so that characters are displayed slowly enough that you can read them. Write your program using Keil uvision. Create a project. Create a new file. Write your program. Save it with the.a51 extension. Add the program to your project and then build your project. When you build your project, be certain that the create hex file flag is checked among the compiler options. The hex file is the file which will be downloaded to the XS40 board. Turn in a copy of your ASM program at the beginning of class.

5 5-5 Table 1 Seven segment display font Character LED Segment A B C D D E F Blank a b c d e f g h i j k l m n o p r t u w y PROCEDURE: 1. Load the program you created in the preliminary assignment into the Keil debugger (in uvision2, the debugger can be accessed directly from uvision. In earlier versions, the debugger is accessed by running the program dscope). Display the contents of external memory at location 5000H by issuing the command d x:0x5000, x:0x5100 in the command window. This displays (d) the contents of external (x) memory locations 0x5000 through 0x5100. These values at these memory locations are shown in the memory window. Set the watch window to watch the seven-segment

6 5-6 display using the command ws <label>, where ws stands for Watch Set and <label> is the label you gave the memory mapped output port at 0xAA55 in the assembly program. Single step through your program at least twice to verify the seven-segment display is receiving the correct value and that your loops function. You can step through the program using the Step Into button on the Module window. In the first part of your program, you should see memory locations beginning at 0x5000 filling with the hex values representing your message. In the second part of your program, you should see these values being written to the seven-segment display (location 0xAA55) one at a time. Find the delay between printing consecutive characters to the seven-segment display and write that value in your lab notebook. If you find any errors in your program, correct them and re-simulate. After you have run through the program twice, and the final (correct) values are displayed in the memory and watch windows, print a screen capture (print screen) and place it in your lab notebook. Circle the value in memory that is currently being displayed on the seven-segment display. 2. Download the source files for the hardware-software debugger GUI from and untar it in your lab1 directory. 3. Transfer the hex-file you created to a Unix machine running the Mentor Graphics software using ftp or floppy disk. Place the file in your lab1 project directory, under the program_files subdirectory. Rename the file to sram.hex. This is the program that Mentor Graphics runs on the 8051 during hardware simulation. If you want to be a bit more organized, you can give the file a meaningful name (like message.hex) and link sram.hex to it by using the ln command, instead of renaming your file. That way, there is less doubt about the actual contents of sram.hex. 4. Load the 8051 simulation model into QuickSim Pro. Trace the signals on RD/, WR/, PSEN/, OE/, P0, P2, and the lines from the external latch to the seven-segment display. You will use the trace to verify the correct signals are shown on these lines, and thus that your hardware design is correct. Force the GlobalSetReset signal as in lab1. Force the RST input to the 8031 low by forcing J1-2 high. 5. Now you will use a hardware-software debugger GUI developed for the simulation model of the 8051 microcontroller to test your design. The debugger is similar to the interface used in lab2 for the Wimp51 model. The hardware-software debugger GUI allows you to look inside the 8051 simulation model while running your software along side your custom hardware. You can easily see the values of internal registers, like the ACC, r0-r7, or the data pointer, see values of memory, step through your code, and more. To invoke the debugger type source 8051.tcl at the prompt of the Vsim (QSPro HDL) window. You will see a window appear (Figure 4) that shows internal registers values on the left of the interface and your assembly-level program on the right.

7 Figure 4. Hardware-Software Debugger GUI 5-7

8 5-8 The Next Instruction button allows you to step through your program one instruction at a time. The instruction register on the top left of the interface shows the instruction that will be executed. The Next Clock button allows you to step through your code one clock cycle at a time. Any time the value of a register changes, that register s box is highlighted in blue. You can also select a break-point in your program and hit the Go To Break Point button to execute till that point and analyze the intermediate results. To select a break-point, just highlight an instruction in your program with the left mouse button. If you want to stop execution (for example, if you end up in an infinite loop), hit the Stop button. You may use the Restart button to restart your program from the beginning. Note that the signal traces in the Quicksim trace window will be erased if you do this. You can look at the values in internal and external memory with the help of the Memory button on the menu bar. The microcontroller on the XS40 board does not have internal code memory. Both code and data are stored in external memory. To view the contents of external memory, hit the Memory selection on the menu bar and select External from the submenu. A sub-window appears in which you can specify the range of memory locations in hexadecimal format and path to the memory module. The memory module is just another VHDL model like the 8051 microcontroller. The path to the memory module is already provided so you just have to specify the range and hit Show Memory button. The memory contents are displayed in another sub-window. You can display up to five different memory windows by choosing a different window number. 6. Display the contents of external memory at location 0000H; this is the location where your code segment begins. Show memory locations 0x0000 to 0x00FF. The memory range should be entered in hexadecimal format as shown above. Let the memory number be 1. Hit the Show Memory button. A sub-window appears displaying your program in machine language i.e. the contents of code memory. 7. Display the contents of external memory at location 0x5000; this is the location where your data is stored. Display memory in the range from 0x5000 to 0x5100. This time select a different memory number, say 2. Hit the Show Memory button to display the contents of your data segment. Both the memory windows will incorporate an Update button at the bottom that can be used to refresh the memory contents. To speed simulation time, memory windows are ONLY updated when they are first instantiated or when the Update button is pressed. 8. To better show what happens at the seven segment display, a special visual interface has been developed. To view this interface, type source sevenseg.tcl at the Vsim window. Whenever a value is written to the seven segment it is displayed in highlighted blue color. 9. Verify the functionality of your program by stepping through it one instruction/one clock cycle at a time or by setting break-points and analyzing intermediate results. Check if correct values are written in the memory and to the seven segment display. Correlate results with the traces of address and datalines shown in the QSPro trace window. Print out a copy of the trace window

9 5-9 (QSPro Quicksim II) for your lab notebook. You will use this later for comparison to the hardware simulation. 10. Transfer both xc4005.bit and sram.hex to the Windows-based PC connected to the XS40 board. Load these files to the XS40 board using the program GXSLOAD. Verify functionality using the same procedure as in Lab 4. Print out a copy of the WE/ and the lines to the seven-segment display for your lab notebook. Compare to your earlier simulation results and explain any differences. If you find problems, you may need to trace signals on PSEN/, RD/, OE/, P0, and/or P2 to find the cause. 11. A disadvantage to simulating software without hardware is that your software simulator has no idea what your hardware configuration is and may give you incorrect results. To truly test your design, you must simulate hardware and software together. Modify your assembly program to position the data segment that was at 5000H to 000AH (XSEG at 000AH). Leave the other segments in the same position they were before. Rebuild your software and re-simulate it with the Keil software development tools. Does the program appear to work correctly? Mark your observations in your lab notebook. Next, simulate your new program with hardware in QuickSim Pro and the hardware-software debugger GUI. In addition to WE/ and the lines to the sevensegment display, trace the address and data lines from P0 and P2. Does the program work now? Is the 8051 loading and executing the instructions we expect it to? Is the data different? Mark your observations in your lab notebook. Print out section of the signal trace when the program goes wrong. Mark in your notebook what data/instructions/signal levels are incorrect. Take your new hex file down to the lab and try it out on the real XS40 board. Does your program work in the actual hardware? QUESTIONS: 1. On the signal trace taken in part 3 of the lab, circle an occasion where a) an instruction was read from code memory and b) a byte was read from data memory. Does OE/ at the RAM chip follow the signals on PSEN/ and/or RD/ from the 8051? Based on your observation, briefly explain how both code and data can be stored in the same RAM chip. 2. Why must we be very careful about the placement of code and data segments when using the XS40 board? Is it acceptable to have both a code and data segment starting at 0000H in memory with the XS40 board? How about with other hardware setups? 3. On the signal trace taken in part 5 of the lab, for 2 or 3 instruction cycles that produced the wrong results, show what instructions were read from memory and also mark which instructions should have been read from memory. What is the cause of this problem? Why isn t the 8051 reading the correct instructions from memory? 4. In part 5 of the lab, why didn t the Keil software development tools detect the problem in your program? Is it sufficient to simulate software by itself, without hardware? Why not? 5. Was the hardware-software debugger GUI necessary for debugging your design? How could you have checked proper operation without it?

10 In your program, you specified a variable to represent the seven-segment display location (something like: XSEG AT 0AA55H and then sevenseg: DS 1 ). Why is it a good idea to use a symbolic address for the output port at 0xAA55 instead of the actual address? That is, for this program, you used instructions like MOV DPTR,#sevenseg, which is technically the same as MOV DPTR,#0AA55H. Why is MOV DPTR,#sevenseg the better choice?

NEW CEIBO DEBUGGER. Menus and Commands

NEW CEIBO DEBUGGER. Menus and Commands NEW CEIBO DEBUGGER Menus and Commands Ceibo Debugger Menus and Commands D.1. Introduction CEIBO DEBUGGER is the latest software available from Ceibo and can be used with most of Ceibo emulators. You will