Program Simulation
The BIN4.HEX file could now be downloaded to the PIC chip and the program executed in hardware. It should run correctly because the program given here is known to be good. However, when a program is first developed, it is quite likely that logical errors will be present.
This means that the program executes but it does not necessarily carry out the right operations in the right order. For example, if the wrong input pin is specified for testing, the button will not be detected. Logical errors can be detected by running the program through a test sequence that exercises all the features of the application. Any operational errors then have to be traced back to the relevant source code section. This process may have to be repeated many times, making it very time consuming.
This is where simulation is useful: it allows the program to be ‘run’ in a virtual environment on the host PC, as if it were being executed in the chip, but without having to download to the actual hardware. It can then be checked for logical errors and the source code changed and re-tested much more quickly and easily. This will allow most of the logical errors to be eliminated, leaving maybe a few issues related to the real hardware to be resolved, e.g. input/ output timing.
MPLAB provides a source code simulation and debugging for the MCU alone, while Proteus VSM provides a much more user-friendly interactive method, with an animated schematic and virtual signal analysis for the whole circuit (see Appendix E). Simulation allows the effect of the program on the registers and outputs to be checked at critical points. For example, in BIN4 we would check to see that port B has been incremented after the execution of the main loop, because this is the primary function of the program. Figure 4.4 shows a screenshot from MPLAB version 8.60 when simulating BIN4.
MPLAB now provides a logic analyzer, which allows the outputs to be viewed on a time axis, as seen in Figure 3.5 by selecting View, Simulator Logic Analyzer. The ‘Channels’ button opens a dialogue that allows the output pins RB0 to RB7 to be added to the display.
Single Stepping
Source code debugging allows the program to be tested in the edit window. First, load and assemble the source code file BIN4.ASM. Then enable simulation mode by selecting ‘Debugger, Select Tool, MPLAB SIM’. A control panel should appear in the toolbar. Operate
the ‘Run’ button: nothing appears to happen, but when the ‘Halt’ button is operated, the current execution point is indicated in the source code window. You may get a message about the ‘Watchdog Timer’, which is an automatic interrupt that prevents the program getting stuck in a loop. If necessary, open the Configure, Configuration Bits dialogue and turn the watchdog timer off, unchecking the ‘Configuration Bits set in code’ option. At the same time, ensure that the Power-Up Timer and Code Protection are off. These will be explained later. The program can now be executed one instruction at a time using the ‘Step Into’ button in the control panel, and the sequence examined. With no inputs, the program should loop through the reset sequence. The program can be restarted from the top at any time by clicking on the ‘Reset’ button. If Animate is selected from the Debugger menu, execution steps automatically.
Input Simulation
We now need to simulate the action of the push buttons in the hardware that are used to start and stop the output sequence. Select Debugger, Stimulus, New Workbook (Asynch tab). Clicking the first cell in the PIN/SFR column allows an input to be selected from a drop-down menu. Select RA0 in the first row, and RA1 in the second. In the Action column, set both to toggle mode: this will make the input change each time the Fire button is pressed. The inputs can now be operated to allow the program to proceed from the reset loop. Both inputs should be set high initially, simulating the default (inactive) condition in the hardware. Taking RA1 low will allow the main loop to proceed, and toggling RA0 will execute the reset loop. Unfortunately, the state of the input is not indicated in the stimulus table, so file register 05, port A, must be displayed (preferably in binary) to confirm the changes on the inputs.
Register Display
The special function registers can be viewed to check the effect of the program on the output register 06, port B. The changes at the inputs can also be checked, and any intermediate changes in internal registers tracked. Registers can also be displayed selectively using a watch window. The display format can be changed from hex to binary by right-clicking for the register properties, so individual bit status can be checked. Port A bits 0 and 1 should change with the asynchronous stimulus inputs, and port B should display a random binary number after the increment loop has been executed for an arbitrary time.
Step Out, Step Over
The Step Into control will step through all subroutines. Once the program has entered the delay loop, the same simple sequence is being repeated, so single stepping is not so useful. We need either to drop out of the subroutine (Step Out) or to bypass it altogether (Step Over). These commands cause the loop to be executed at full speed, with single stepping being resumed after the RETURN instruction. Once a subroutine is correct, it can be stepped over when debugging the rest of the program.
Breakpoints
Another technique for executing selected parts of the program at full speed is the breakpoint. For example, if part of a large program is known to be correct, we will want to run through that section at full speed and start single stepping at a later point in the program. In BIN4,
a breakpoint can be set at the start of the main loop so that it executes once, then stops so we can inspect the registers. A breakpoint can be set by simply double-clicking in the line number margin of the source code window. The program can then be run from the start, and it will stop at the breakpoint. Run again, and a complete loop will be executed at full speed and port B should be seen to increment by one.
Stopwatch
The program timing can be checked using the stopwatch feature. This displays the total number of instructions executed and the time elapsed, calculated from the simulated processor clock frequency. For BIN4, RC oscillator should be selected in the configuration dialogue. The clock speed is set in the Debugger, Settings dialogue, Osc/Trace tab. In this case, set the processor frequency to 100 kHz. Then run the program to the breakpoint at ‘start’, zero the clock and run again. The stopwatch will display the total time for one cycle. The frequency of the output can be predicted from this measurement. Two program loop cycles will cause the low-output bit RB0 to be toggled up and down once, giving one full output cycle. Therefore, we can double the loop time to give the output period, and calculate the reciprocal to give the frequency at RB0.
This shows that changes in the higher order output bits will be clearly visible using this clock frequency with the maximum delay loop count (FF). The frequency at RB1 will be about 8 Hz, RB2 4 Hz, RB3 2 Hz and so on, with RB7 flashing about once every 8 s. By adjusting the count value, and inserting NOP (no operation) instructions, an exact set of frequencies can be obtained. Using a crystal clock or calibrated internal clock will make the timing more accurate. More information about using MPLAB for debugging is given in Chapter 9.