Which of the following types of errors occur while a program is executing?

11.1 Syntax errors

Syntax errors are typing errors in MATLAB statements [e.g., plog instead of plot]. They are the most frequent type of error, and are fatal: MATLAB stops execution and displays an error message. As MATLAB evolves from one version to the next, error messages improve. Try the following examples to examine the latest error messages:

     2*[1+3

     disp[['the answer is ' num2str[2]]

There are many possible syntax errors—you will probably have discovered a few yourself. With experience you will become more adept at spotting your mistakes.

The function lasterr returns the last error message generated.

Application Debugging and Testing

The application program is tested and debugged in several stages. The main types of errors and the tools for detecting them are outlined next.

Syntax errors are mistakes in the source code, such as spelling and punctuation errors, incorrect labels, and so on, which cause an error message to be generated by the compiler. These appear in a separate error window, with the error type and line number indicated so that it can be corrected in the edit window.

When the program is successfully compiled, it can be tested for correct function in the target hardware so that any logical errors can be identified. However, it is preferable to test it in software simulation mode first, as it is quicker and easier to identify errors in the program sequence. Two simulation methods are available here, MPSIM and Proteus VSM.

MPSIM is the simulator provided with MPLAB. It allows the program source code to be run, stopped and stepped, and breakpoints set. The registers and source variables may be inspected at each step. When debugging C programs, breakpoints are the most useful, while stepping is more useful in assembly language. The program sequence and variable values are monitored and errors identified when the results obtained do not agree with those expected. Error information is provided principally in tabular form.

By comparison, the Proteus VSM debugging environment has significant advantages. The animated schematic gives a much more immediate indication of the overall program function. Interactive input and output devices operate in real or simulated time. The source code and breakpoints can be displayed.

In addition, if the VSM viewer is run from within MPLAB, the progress of the program can also be monitored simultaneously in MPSIM. Therefore, the more detailed debugging tools in MPSIM can be run alongside VSM and the most appropriate selected for any debugging task. The simulated hardware design is thus tested in conjunction with the MCU firmware [cosimulation], allowing circuit modifications at an early stage and hardware-software interaction to be studied on screen. When the program is eventually downloaded to the real hardware, it is now far more likely that it will work the first time.

The VSM Viewer is invoked from the debug tools menu in MPLAB, and the program is attached and tested. However, if circuit modifications are needed, VSM must be opened separately to run alongside MPLAB, so that the full set of ISIS schematic edit tools and component models are available. VSM still accesses the same COF file, so both software and hardware changes can be tested. More details on interactive debugging are given in Appendices A, B, and CAppendix AAppendix BAppendix C.

4.4 Debugging a Function

The basics of the MATLAB debugger were described in Section 1.12. Here, we consider some of the types of errors that the debugger can be used to help identify and fix.

When writing a program or function that is non-trivial, the chances of it working perfectly first time are quite low, even for a skilled MATLAB user. Debugging tools are there to help identify why a program does not work correctly or as expected.

When debugging, we need to work systematically and run our program with various sets of test data to find errors and correct them when we find them. If we work incrementally as we did in Example 4.1 above, then the repeated nature of the testing allows errors to be caught earlier, which reduces the chance of later errors occurring or minimizes their severity.

There are three main types of error that a function or program can contain:

Syntax errors.

Run-time errors.

Logic errors.

The term ‘syntax’ relates to the grammar of the programming language. Each language has a specific set of rules for how commands can be written in that language and these rules are collectively known as the language's syntax.

When a line in a MATLAB function contains a syntax error, the built-in Code Analyzer [see Section 1.12.2] should highlight in red the corresponding line of code. Hovering the mouse over the line should result in a message being displayed to the user that describes what MATLAB has decided is the particular syntax error in the line. In other words, MATLAB can detect an error with the script or function before it is run.

The reason for this syntax error is that the

The problem with the code in Example 4.4 is related to the choice of variable names. The sums of the arrays

Using the name of a built-in function for a variable that we use locally is called shadowing. We can check if a name is already used by MATLAB or in the workspace using the

The return value of 5 indicates that the name

The value of 0 returned indicates that the name

Returning to the code in Example 4.4, when the execution reaches line 13, the programmer's intention was to use the built-in MATLAB function called

Apart from giving an example of a run-time error this example shows why it is very important not to give names to variables that are already used to refer to built-in functions. MATLAB will not complain when you do this so be careful!

The script in Example 4.5 calls

Logic Errors

Logic errors can be some of the hardest to find, and identifying them often requires using the debugger to carry out careful line-by-line inspection of the code as it is running. This is because no error is reported by MATLAB and the Code Analyzer does not highlight anything either. However, when the code is run, an incorrect output or behavior results and MATLAB will generally not provide a clue as to why this happened.

This shows two numbers that are clearly not equal so what has gone wrong?

To track down the reason for the behavior in Example 4.6 we need to carry out some further investigation. In the command window we can look at the help on the

  >> help sin
   sin    Sine of argument in radians.
      sin[X] is the sine of the elements of X.

This shows that the built-in MATLAB trigonometric function

Because no error message is given, logic errors can be difficult to detect. Sometimes we might not even notice that the program or function is behaving wrongly. Even when we suspect a logic error exists, by noticing something incorrect in the program's behavior, it can still be difficult to pinpoint where the error is. There is no error message helpfully pointing us to a specific line in the code, as in the case of syntax errors. Worse still, the error will not necessarily be restricted to just one line – it can arise from the way different sections of code interact.

The error in the previous example was due to the intention to use degrees where radians should have been used instead. This is only noticed by observing the actual values of the output and seeing that the numeric value is not correct; in other words, by careful inspection of the output.

One way to identify logic errors in a function is to use the MATLAB interactive debugger to step through the function line-by-line, perhaps with a calculator or pencil and paper to hand [see Section 1.12].

Another way is to take each line of the code and copy-and-paste it into the command window, executing each line at a time and assessing its result to see if it is right.

Putting lots of statements in the code that display output and the values of the most relevant variables using the

4.6.1 Syntax Errors

If there are any syntax errors in the source code, such as spelling, layout, punctuation or failure to define labels properly, error messages will be generated by the assembler. These will be displayed in a separate window, indicating the type of error and line number. The messages and line numbers must be noted, or the error file, BIN4.ERR, printed out then the necessary changes made to the source code. The error is sometimes on a previous line to the one indicated, and sometimes a single error can generate more than one message. Warnings and information messages can usually be ignored, and can be disabled. There are more details about error messages in Chapter 9.

You may receive the following messages:

 Warning[224] C:\MPLAB\BOOKPRGS\BIN4.ASM 65 : Use of this instruction is not recommended.

 Message[305] C:\MPLAB\BOOKPRGS\BIN4.ASM 81 : Using default destination of 1 [file].

The first warning is caused by the special instruction TRIS, which is not part of the main instruction set. It is a simple way of initializing the port, and there is an alternative method using register bank selection, which is preferred in real applications. This will be introduced later.

The message about the ‘default destination’ is caused by the simplified syntax used in these programs, where the file register is not explicitly specified as the destination in instructions where the result can be placed in either the file register or the working register. The assembler assumes that the file register is the destination by default, and we are taking advantage of this to simplify the source code.

When all errors have been eliminated and the program has been successfully assembled, the machine code can be inspected by selecting ‘View’, ‘Program Memory’. Note that the source code labels are not reproduced, as the program code has been ‘disassembled’ [recreated] from the machine code. That is, the hex file has been converted back to mnemonic form so that it can be checked against the original.

Lesson 8.1 MATLAB® Debugging