|
Arabic
Bengali
Chinese
English
French
German
Hebrew
Hindi
Italian
Japanese
Korean
Malay
Polish
Portuguese
Spanish
Turkish
Ukrainian
Vietnamese|
ENCYCLOPEDIA OF RADIO ELECTRONICS AND ELECTRICAL ENGINEERING Debugging microcontrollers using a ROM emulator. Encyclopedia of radio electronics and electrical engineering
Encyclopedia of radio electronics and electrical engineering / Microcontrollers The complexity of developing and debugging the working program of an electronic device containing a microprocessor often determines the cost of its development as a whole. In microcontrollers (MC), which have integrated memory and some peripheral devices, this is especially pronounced. One of the tools that greatly facilitate debugging is the ROM emulator described in [1]. The proposed article describes the technology of working with it. Debugging capabilities are not limited to the methods outlined. This process, as well as designing in general, is to a certain extent an art: for the same instrument, everyone creates "his own music". We will be grateful to readers who will share their original tools and methods for debugging MK programs. The complexity and laboriousness of the process of debugging MC software is determined by the following factors [2]:
Traditional test equipment (such as an oscilloscope) can only be used to a limited extent for debugging the MCU. The simplest (and at the same time the most inefficient) debugging method is the “trial and error method”: loading the program into a reprogrammable read-only memory (EPROM), trying to execute it, detecting and correcting errors in the program and hardware, erasing the EPROM, reloading the program, etc. e. The processes of erasing and writing data to the EPROM chip take a long time, and after a certain number of reprogramming cycles, it generally fails. Repeated installation and removal of the microcircuit reduces the reliability of the electrical contacts in the EPROM socket. The possibility of obtaining debugging information about the system is practically absent. Currently, MK is most often debugged by cross-tools based on a personal computer. This allows minimal distraction of MC resources. The device to be debugged, as shown in the figure, is connected to the computer through some tool, such as a ROM emulator. Such a complex allows you to download and edit the program, enter test modules into it, obtain certain information about the system, and much more, which we will discuss below. Although ROM emulators are not the only and not the most powerful debugging tool, they are still popular. Their "longevity" is explained by independence from the type of MC (only the ability to work with external program memory is needed), real-time operation, low price and accessibility to a wide range of equipment developers and radio amateurs. We will consider the technology of debugging a program using a ROM emulator using the example of the MCS-51 family of MKs (8031, 8051, 80C31, 80C51. KR1816BE31, KR1816BE51, KR1830BE31, KR1830BE51, etc.). Starting debugging, it is necessary to check the operability of the hardware of the system and the MC itself. To do this, you can use the "free count" tests [3]. which consist in the enumeration of all possible code combinations on the lines of the MK ports. During testing, the port lines will be set to the output state, so first of all, make sure, according to the device being debugged, that they are not loaded on the outputs of other elements. Temporarily disconnect such loads, if any. Load the ROM emulator with No Operation (NOP) command codes within the entire address space of the MCU programs. For MCS-51 this is code 00H. When executing such a "program", the MK sequentially goes through all the addresses of the program memory. Monitor the signals of ALE, PME and ports P0, P2 with an oscilloscope. The waveforms on the port lines must match the timing diagrams of the binary counter, taking into account the multiplexing on P0 of the low byte of the address and data. Next, check the ports P1 and P1 by loading the test program shown in Table 00 into the ROM emulator. 0. It outputs a sequence of codes from XNUMXH to XNUMXFFH on the lines of the specified ports, simulating an eight-bit binary counter. If the oscillograms correspond to the required ones, restore the loads disconnected from the ports and proceed to debugging the working program of the MC. Remember that you are debugging the software and hardware of the system at the same time, and do not forget to periodically monitor the signals at the test points with the oscilloscope. The inconsistency of the type of signals with your ideas about them is a reason for serious reflection and additional checks.
To facilitate development and debugging, one should adhere to the modular principle of programming, i.e., divide the MK program into parts according to a functional feature. This will allow you to easily move individual modules, and if necessary, apply them in other projects. The module to which control is transferred after power is turned on or the MK is reset is called the main or main. Transferring control to the program entry point should be a jump command, not a subroutine call, so as not to pollute the stack with the return address. To avoid unexpected program results, remember to assign an initial value to each of the variables before you use it for the first time. In some cases, you may need to initialize peripheral equipment. The initialization block is placed at the beginning of the main program module. An approximate view of the main program module at the beginning of debugging is shown in Table. 2. It contains only the entry point to the program and the exit handler. Although such an output is rarely used in microcontroller systems, it must be provided for the correct termination of emergency situations. In the example under consideration, after the completion of the work, the program "loops". Only restarting the system with a hardware reset signal will bring it out of this state.
During debugging, other program modules are added to the main module as they are ready. The order of their connection and debugging plays an important role. You should start with the drivers for information output devices (display, digital-to-analog converter, etc.), placing their calls in the main module. Then they debug the drivers of other peripheral devices, data processing routines, and only after that they check the joint operation of all program modules. If there is an alphanumeric display, its driver is debugged first and used later to display debugging information, for example, the contents of the internal data memory of the MK. If such a ROM emulator is used that the information contained in it can be written and read by both the control computer and the device being debugged, the MK can place the debug data in the free memory area of the ROM emulator, and the control computer reads them and displays them on its display. For example, to output the contents of the MCU's internal data RAM, connect its external data memory write (WR) signal output to the ROM emulator's write signal input and use the subroutine shown in Table 3. 32. It is assumed that the amount of program memory of the device being debugged does not exceed 8000 KB, so the debug information placed in the emulator's memory starts at address 0H. The contents of the registers R1 and R8000 are sent separately, since they are later used in the subroutine to organize the loop. After the debugging information is output, the MK program is suspended, the contents of the memory cells of the 807H-XNUMXFH ROM emulator are read by the control computer, displayed and analyzed. Similarly, the contents of all programmatically accessible MC registers can be displayed.
When starting to debug a peripheral device driver, temporarily disable the control signals generated by the MK from it in order to avoid possible device failure due to errors in the program. If the process is of a one-time nature, "loop" it and program the oscilloscope clock signal if necessary. Debug the driver by monitoring the signals generated by the oscilloscope. After making sure that the timing diagrams of the control signals correspond to the required ones, connect the peripheral device and continue debugging the driver on real hardware. Finally, remove the debugging elements from the program module and check its operation in the final form. The use of shared MK resources by different modules quite often leads to the fact that the debugged program stops working when another subroutine is added. Therefore, after debugging the next module, make sure that all previously debugged drivers and subroutines continue to work correctly. If your program uses interrupts, do not disable them unless absolutely necessary. A debugged module should not be removed from the program, even if it is not currently needed. When the MK "freezes", the following error localization method is useful: enter control points into the program that display sequentially increasing numbers. After "hanging" the display will show the number corresponding to the last successfully passed control point. If several such points are caught in an infinite loop, the numbers on the display will change rapidly. In order to determine exactly which points are in the cycle, you will have to artificially slow down the change of numbers by setting a program delay when outputting each of them, for example, in the form of an idle cycle. If the system being debugged does not have a built-in display, information can be displayed on the display of the host computer through the free memory area of the ROM emulator. After debugging all device drivers, start debugging other subroutines. If any of them implements a complex algorithm for processing or converting data, displaying one or more intermediate values of variables often does not provide information sufficient for error analysis. Overcoming difficulties and writing debugging information of the required amount into the free memory area of the ROM emulator will help to overcome difficulties. Having achieved the normal operation of all program modules, you can debug them together. The difficulties that arise in this case are divided into two groups. The first includes the problems of sharing common MK resources: arithmetic logic unit, data memory, input-output ports. The second is related to the operation of microcontroller devices in real time. Real-time systems are usually multi-threaded. Several program tasks (threads) are executed in parallel, interacting with each other and using common resources. But at each moment, the MC, due to its structure, solves only one of them, switching to others in turn, taking into account the priority. Conflicts between tasks arise both due to lack of resources and due to lack of time for data processing. Therefore, pay special attention to the MK resources used in program modules, often control the change in their state by displaying debug information. Try to reduce the number of global variables, replacing them with local ones whenever possible. Monitor the state of the stack. Estimate the execution time of critical sections of the program, check the system with various values of input signals that are possible in practice. Using the ROM emulator, you can also debug a program designed to work in the internal memory of the MK, if you temporarily place it in the external program memory. Since in this case the ports P0 and P2 will be occupied by servicing external memory, then if the remaining free I / O lines of the MK are not enough, P0 and P2 are replaced with I / O ports addressed as external data memory cells. They are connected according to standard schemes, using trigger registers to increase the number of output lines, and the number of input lines - elements with three output states. After debugging the system using the emulator, remove debugging elements from it, write the program to ROM (or to the internal program memory of the MK) and check the operation of the device in its final form. Literature
Authors: G.Vydolob, V.Samoylov, Moscow (Zelenograd)
Machine for thinning flowers in gardens
02.05.2024 Advanced Infrared Microscope
02.05.2024 Air trap for insects
01.05.2024
▪ Toshiba Canvio Alu Portable Drive ▪ FTR-H3 relay series from FUJITSU COMPONENTS
▪ section of the site Car. Article selection ▪ article There are only girls in jazz. Popular expression ▪ article Where did the first schools originate? Detailed answer ▪ article Partial use of insurance premiums by policyholders for the prevention of insured events
Home page | Library | Articles | Website map | Site Reviews
www.diagram.com.ua |
See other articles Section 
Latest news of science and technology, new electronics:
All languages of this page