Debugging (C-SPY)
31. It is possible to use C-SPY to get control of a running device whose state is unknown. Simply
use C-SPY to program a dummy device, and then start the application with Release JTAG on Go
selected. Remove the JTAG connector from the dummy device and connect to the unknown device.
Select Debug → Break (or the Stop hand) to stop the unknown device. The state of the device can
then be interrogated.
32. Reseting a program temporarily requires a breakpoint if Project → Options → Debugger → Setup →
Run To is enabled. If N or more breakpoints are set, Reset sets a virtual breakpoint and runs to the
Run To function. Consequently, it may require a significant amount of time before the program
resets (i.e., stops at the Run To function). During this time the C-SPY indicates that the program is
running, and C-SPY windows may be blank (or may not be correctly updated).
33. Run To Cursor temporarily requires a breakpoint. If N breakpoints are set and virtual breakpoints are
disabled, Run To Cursor incorrectly uses a virtual breakpoint. This results in very slow program
execution.
34. The simulator is a CPU core simulator only; peripherals are not simulated, and interrupts are
statistical events.
35. On devices without data breakpoint capabilities, it's possible to associate with an instruction breakpoint
an (arbitrarily complex) expression that C-SPY evaluates when the breakpoint is hit. This mechanism
can be used to synthesize a data breakpoint. See the C-SPY documentation for a description of this
complex breakpoint mechanism.
36. The ROM Monitor referenced by the C-SPY documentation applies only to older MSP430Exxx
(EPROM) based devices; it can be ignored when using the FET and the Flash-based MSP430F
devices.
37. Special function registers (SFRs) and the peripheral registers are displayed in View → Register.
38. The putchar()/getchar() breakpoints are set only if these functions are present (and the
mechanism is enabled). Note that putchar()/getchar() could be indirectly referenced by a library
function.
39. The Flash program/download progress bar does not update gradually. This behavior is to be
expected. The progress bar updates whenever a "chunk" of memory is written to Flash. The
development tools attempt to minimize the number of program chunks to maximize programming
efficiency. Consequently, it is possible, for example, for a 60K-byte program to be reduced to a single
chunk, and the progress bar is updated until the entire write operation is complete.
36 Frequently Asked Questions SLAU138F – June 2004 – Revised March 2007
Submit Documentation Feedback
To Next Page
Loading...
Need help?
General
