
www.ti.com
A.1
Hardware
Hardware
1. The state of the device (CPU registers, RAM memory, etc.) is undefined following a reset.
Exceptions to the above statement are that the PC is loaded with the word at 0xFFFE (i.e., the reset
vector), the status register is cleared, and the peripheral registers (SFRs) are initialized as documented
in the device-family user's guides. C-SPY resets the device after programming it.
2. MSP430F22xx Target Socket Module (MSP-TS430DA38) – Important Information
Due to the large capacitive coupling introduced by the device socket between the adjacent signals
XIN/P2.6 (socket pin 6) and RST/SBWTDIO (socket pin 7), in-system debugging can disturb the
LFXT1 low-frequency crystal oscillator operation (ACLK). This behavior only applies to the Spy-Bi-Wire
(2-wire) JTAG configuration and only to the period while a debug session is active.
Workarounds:
•
Use the 4-wire JTAG mode debug configuration instead of the Spy-Bi-Wire (2-wire) JTAG
configuration. This can be achieved by placing jumpers JP4 through JP9 accordingly.
•
Use the debugger option “Release JTAG On Go” that can be selected from the IDE drop down
menu. This will prevent the debugger from accessing the MSP430 while the application is running.
Note that in this mode a manual halt is required to see if a breakpoint was hit. Refer to the IDE
documentation for more information on this feature.
•
Use an external clock source to drive XIN directly.
3. With current interface hardware and software, there is a weakness when adapting target boards that
are powered externally. This leads to an accidental fuse check in the MSP430. This is valid for PIF and
UIF but is mainly seen on UIF. A solution is being developed.
Workarounds:
•
Connect RST/NMI pin to JTAG header (pin 11), LPT/USB tools are able to pull the RST line, which
alsos reset the device internal fuse logic.
•
Use the debugger option "Release JTAG On Go" that can be selected from the IDE dropdown
menu. This prevents the debugger from accessing the MSP430 while the application is running.
Note that in this mode, a manual halt is required to see if a breakpoint was hit. See the IDE
documentation for more information on this feature.
•
Use an external clock source to drive XIN directly.
4. When the MSP-FET430X110 is used as an interface to an MSP430 on the user's circuit (i.e., there is
no MSP430 device in the FET socket), the XOUT and XIN signals from the FET should not be
connected to the corresponding pins of the in-circuit MSP430. Similarly, when using the interface
module, do not connect the XOUT and XIN signals from the interface module to the corresponding pins
of the in-circuit MSP430.
5. The 14-conductor cable connecting the FET interface module and the target socket module must not
exceed 8 inches (20 centimeters) in length.
6. The signal assignment on the 14-conductor cable is identical for the parallel port interface and the
USB FET.
7. To utilize the on-chip ADC voltage references, C6 (10
µ
F, 6.3 V, low leakage) must be installed on
the target socket module.
8. Crystals/resonators Q1 and Q2 (if applicable) are not provided on the target socket module. For
MSP430 devices that contain user-selectable loading capacitors, the effective capacitance is the
selected capacitance plus 3 pF (pad capacitance) divided by two.
9. Crystals/resonators have no effect on the operation of the tool and C-SPY (as any required
clocking/timing is derived from the internal DCO/FLL).
10. On 20-pin and 28-pin devices with multiplexed port/JTAG pins (P1.4 to P1.7), it is required that
"Release JTAG On Go" be selected to use these pins in their port capacity. See
for
additional information regarding this mechanism.
11. As an alternative to sharing the JTAG and port pins (on 20 and 28 pin devices), consider using
an MSP430 device that is a "superset" of the smaller device. A very powerful feature of the
MSP430 is that the family members are code and architecturally compatible, so code developed on
one device (for example, one without shared JTAG and port pins) ports effortlessly to another
(assuming an equivalent set of peripherals).
30
Frequently Asked Questions
SLAU138F – June 2004 – Revised March 2007