<< Chapter < Page Chapter >> Page >

- Break in stack overflow : Generates the suspension of the execution of the application whenever the SP register value assumes a lower value than the specified one. This breakpoint is implemented using only one trigger;

- Breakpoint : Generates the suspension of the execution of the application whenever the memory bus address takes the value specified. This breakpoint is implemented using only one trigger;

- Hardware breakpoint : Generates the suspension of the execution of the application whenever the memory bus address takes the value specified. This breakpoint is implemented using only one trigger;

- Watch on data address range : Generates a suspension of the execution of the application whenever the specified data memory addresses range is accessed. It uses two triggers to define the range of addresses;

- Watchpoint : Generates the suspension of the execution of the application whenever a specified data memory address is accessed. It uses a trigger to generate the watchpoint;

- Watchpoint with data : Generates the suspension of the execution of the application whenever a specified data memory address is accessed and the value of the address is equal to specified value. Two triggers are used to implement this watch.

Code execution verification

In order to verify the code execution, it is necessary to use support tools to complete this task. CCE provides a set of features with this aim.

A breakpoint suspends the execution of the application in order to check the status of the system. The activation, deactivation and configuration of these breakpoints are possible through CCE.

There are two types of breakpoints: software and hardware. While the first type of breakpoint is implemented through the insertion of code in the application, in a way invisible to the user, the second type is implemented internally by the device’s hardware. Although the software breakpoints are not limited, the hardware breakpoints, depending on the device, have a limit of 2 to 4 breakpoints.

The application debugging process often requires access to the actual values of the variables. The Variable view allows the user to monitor the application’s local and global variables. In this view, the CCE automatically displays the name and contents of the local variables of the function that is being executed. It is also possible to add the name of other local variables or global variables to be monitored in the debugging process.

The values of the local variables can be modified. The values of the variables that have been changed during the last instruction execution are displayed in red. However, the variable names cannot be modified. It is allowed to change the representation format of the variable: Natural, decimal or hexadecimal. The variables that contain more than one element, such as arrays, structures, or pointers are presented with a (+) sign immediately after the name. This signal means that the variable has elements that can be seen through the expansion of the (+) sign, passing this signal (-), which allows the structure to be collapsed.

The local variables cannot be added or removed from the Variables view. However, global variables can be added or removed. The local variables can be disabled in order to freeze their value as the program is executed.

The Expressions view accepts the entry of expressions to evaluate them as the program is executed. These expressions are written in syntax similar to that used by the C programming language.

The commands accessible through the context menu can

- Specify the number of elements of the array to be displayed in the Expression view: The command Display as Array can be used to display the elements of any pointer or array. The command Remove Array Expansion is used to return an expanded variable back to its original state;

- Change value: Changes the content of the variable;

- Cast to type: Performs a promotion (cast) for a different type of variable;

- Restore Original Type: Restores the expression for the original data type.

The memory window of the debug perspective

The Memory window of the Debug perspective allows the user to monitor and modify the device’s memory. The memory is provided with a list of Memory Monitors . Each monitor represents a section of memory specified by its named location base address. Each memory monitor may be represented in different data formats (memory renderings). The debugger allows four different types of rendering:

- Hex (default);

- Ascii;

- Integer signed;

- Unsigned integer.

The Memory view has two panels:

- Memory Monitors;

- Memory Renderings.

The first panel displays the memory monitors list added to the debug session. The second panel is controlled by selection in the first one and consists of tabs that display the rendering. This panel can be configured to display both renderings.

Request the MSP430 Teaching ROM Materials here (External Link)

Get Jobilize Job Search Mobile App in your pocket Now!

Get it on Google Play Download on the App Store Now




Source:  OpenStax, Teaching and classroom laboratories based on the “ez430” and "experimenter's board" msp430 microcontroller platforms and code composer essentials. OpenStax CNX. May 19, 2009 Download for free at http://cnx.org/content/col10706/1.3
Google Play and the Google Play logo are trademarks of Google Inc.

Notification Switch

Would you like to follow the 'Teaching and classroom laboratories based on the “ez430” and "experimenter's board" msp430 microcontroller platforms and code composer essentials' conversation and receive update notifications?

Ask