Online Postgraduate Courses for the Electronics Industry

Provided By The University of Bolton

• Home
• About Us
• Questions & Answers
• Courses
• Students
• Links

Useful Tools

Microcontrollers

So, we are going to be using 'MPLAB' software for code-simulation and step-thru of the assembler code, and we will use the 'C2C' environment for producing the machine code for downloading to the MatrixMultimedia development board via the parallel (version-2 MMM boards) or USB (version-3 MMM boards) connection. Numerous versions of these softwares exist and some students may already have a preference for using one specific version. It is recommended that the student works through the course notes using the software versions supplied, then if they wish, can apply the same examples and exercises on their preferred versions later on (to reinforce thorough understanding). These notes are currently based on MPLAB v5.50. (Newer versions of MPLAB may produce some incompatibility 'headaches' when trying to integrate with some third party software.) However the principles of understanding and operation are similar, so, following through these notes on an earlier version should not impair the learning experience.

Also associated with the C4PICmicros software there are several versions of the PICmicrocontroller Parallel Programmer (PPP) that can be used as a stand alone program to down-load your code to the MMM boards. As with most software creation and programming methodologies, there are numerous ways of tackling the same problem, which lead to a variety of equally viable solutions.

Practical Session 4: Setting Breakpoints and Using the Trace Feature

Setting Breakpoints

Going back to the MPLAB Integrated Design Environment, and the simulation of code within it, a problem arises when single stepping through a program that contains a software time delay. One finds oneself stepping through numerous decrement to zero instructions.

One way around this is to change the initial value (the value to be decremented) to something small. The delay time is effectively reduced whilst maintaining the functionality of the program.

Another method is to incorporate breakpoints into the program. Setting breakpoints allows the programmer to run, in 'pseudo' real time, sections of the program that have already been checked for accuracy, whilst still being able to single step through unchecked code. In conjunction with the stopwatch software, time delays can be timed precisely.

Consider the following program

Type in the following stimulus file, save it as pulse.sti and include it as the stimulus file for this project, ie. select Simulator stimulus and then Pin Stimulus from the Debug menu.
Enter pulse.sti and click on OK.
 

Single step through the program to ensure that the function of the program is understood. The problem arises when the software delay routine is entered.

To overcome this problem set a breakpoint at 'enddly'.

This is achieved by first of all clicking on Break Settings in the Debug Menu. The Breakpoint Settings Menu will open.
Enter 'enddly' in the start box and click on the tick to accept.
Close the Breakpoint settings window.

A breakpoint has been set to occur when the program reaches the label enddly (this should be indicated in the program by the particular instruction of interest turning red). The program can be single stepped until the software delay is reached and then run in 'pseudo' real time by clicking on the green 'traffic light' soft key. The simulator will run through the time delay subroutine (the bottom of the screen turns blue) and automatically stop at the specified breakpoint. It is now possible to single step through the rest of the program.

Two breakpoints can be inserted into the program to accurately measure the time required to execute the time delay subroutine.

Leave the previous breakpoint in the program, but add another at the entry of the subroutine. The subroutine is now bounded by two breakpoints.

To measure the duration of the time delay, click on the reset softkey and then click on the green 'traffic light' softkey to run the program. The program will halt at the first breakpoint.

Zero the stopwatch and then click on the green softkey to continue program execution. The program will halt at the second breakpoint (at the end of the subroutine).

The stopwatch will contain the time required to execute the subroutine (5ms).

Calculate the delay time by inspecting the program. (This is a relatively straightforward calculation bearing in mind that the target system in the lab operates from a 4MHz clock, implying that an instruction is executed every microsecond).
 

The Trace Facility

The trace facility allows the programmer to store in the trace buffer all the lines of program that are executed and then display them in the trace buffer window. This is another useful software debugging tool.
 

The trace facility can be illustrated as follows:

From the Debug menu select Clear All Points. (This clears all breakpoint settings from the previous section).
Open the Trace settings window from the Debug window.
Set trace settings to start at 'init' and to end at 'enddly'.
The program within the trace points turns green.

Reset the program and the stopwatch.
Run the program for several seconds by clicking on the green 'traffic light' softkey.
Halt program execution by clicking on the red 'traffic light' softkey.

Open the Trace memory window in the Window menu. The Trace memory window displays all the lines of program executed. Notice how the loop waiting for RA0 to go low is executed a number of times before RA0 actually goes low on step 20.

Using the trace memory it is possible to observe exactly which lines of program were executed and when they were executed.

[Link to Practical Session 5]

[back to top]

Updated 21.06.07 ML

Site Search

Powered by Google
Site Map