SBW Connection Problem

Hi Dan,

be shure to connect your MSP-FET430UIF as shown on page 28, Fig. 2.2 of the MSP430 hardware users manual (http://focus.ti.com/lit/ug/slau278e/slau278e.pdf). Be shure to connect JTAG pin4 so the tool can sense the voltage level of your target.

Rgds
aBUGSworstnightmare

It is connected like in Fig. 2.2.

Pin 4 is also connected to Vcc.

I have also noticed the problem has started to happen on the evaluation board too.

What is the voltage you power your board and what is the voltage teh programmer applies to the JTAG pins?

If you power your MSP with a significantly lower voltage (>0.2V difference) it may be that you're routing current through the JTAG pins and their clamp diodes to VCC, which can finally burn out the clamp diodes and then the JTAG pins.

I power the board with 3.3V

The voltage on the TDO/TDI is the same 3.3V because of the pull up resistor.

The voltage on the TCK is 3.1V.

Hi Dan,

you can adjust the voltage level of the MSP-FET430UIF under the debugger options of your project.

Rgds
aBUGSworstnightmare

I don't see how that would help.  My voltage is above the JTAG voltage.  I also have an MSP-TS430PZ5x100 board setup with the 3.3v external with SBW mode and that works most of the time.

Although I did have two chips fail on me today in SBW mode with the MSP-TS430PZ5x100 board.

Dan said:

I power the board with 3.3V
The voltage on the TCK is 3.1V.

Then it doesn't matter. Neither back nor forth.

Dan said:

The voltage on the TDO/TDI is the same 3.3V because of the pull up resistor.

This is not necessarily true. The pullup resistor jsut adjusts the voltage level for inputs with a much higher impedance than its own value. If an output voltage is more than 0.2V different from the other sides VCC, the input pin becomes low-impedance (through the clamp diodes) and the pullups become a don't care.

One problem I can think of is the order in which both sides are powered. If the FET is always powered, but the target board isn't (or vice versa), the output pins of the active one are pumping maximum current into the other sides input pins. The MSP can withstand much stress, but over time...

The newest Olimex programmers have serial resistors on all lines to avoid this, but previous ones and (I think) the TI FETs haven't.

Also check the 'known issues' with the MSP430 programming related to the FET  UIF specifically and secondarily with Code Composer or whatever tools you use.

If I recall correctly there's an unresolved 'known issue' listed still for using the FETs except for the parallel port models in conjunction with externally powered targets even though that scenario is officially supported and 'supposed to work' if you follow the JTAG interfacing guidelines as you have done.  So maybe something related to that has caused unreliability of the JTAG operation though what you have described sounds more like cumulative device damage to either the FET or the target or both.

They weren't all that clear on the cause or technical details of why they warn people that it may not work, so I don't know if that could have caused FET or target damage or the unreliability symptoms you have described.

Another thing to beware of not specifically FET related is just the opportunity for ESD or EMI related problems every time you handle and interface to a target board.  It doesn't take much ESD to cause cumulative damage and eventual flakiness and malfunction of a target board, and that has been the root of many progressively deteriorating and unreliably operating targets I've seen over the years (not just MSP430, just in general).

 

 

 

C. Hayes said:

If I recall correctly there's an unresolved 'known issue' listed still for using the FETs except for the parallel port models in conjunction with externally powered targets even though that scenario is officially supported and 'supposed to work' if you follow the JTAG interfacing guidelines as you have done. 

 

I found where I had read about that and other useful warnings -- SLAU278E, the MSP430 hardware tools users guide PDF file.

A.1 Hardware FAQs
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. The CCE/CCS debugger and C-SPY reset 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 applies only 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 "Run Free" that can be selected from the Advanced Run drop-down
menu (at top of Debug View). 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.
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
also resets the device internal fuse logic.
• Use the debugger option "Release JTAG On Go" that can be selected from the IDE drop-down
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. The 14-conductor cable connecting the FET interface module and the target socket module must not
exceed 8 inches (20 centimeters) in length.

 

MSP-FET430UIF Current detection algorithm of the UIF firmware
Problem Description If high current is detected, the ICC Monitor algorithm stays in a loop of frequently
switching on and off the target power supply. This power switching puts some MSP430
devices such as the MSP430F5438 in a state that requires a power cycle to return the
device to JTAG control.
A side issue is that if the UIF firmware has entered this switch on / switch off loop, it is
not possible to turn off the power supply to the target by calling MSP430_VCC(0). A
power cycle is required to remove the device from this state.
Solution IAR KickStart and Code Composer Essentials that have the MSP430.dll version
2.04.00.003 and higher do not show this problem. Update the software development tool
to this version or higher to update the MSP-FET430UIF firmware.

et. al.

 

Thanks for your responses.

I ended up changing the programming method for the msp430 to JTAG on the next boards.

I have been very careful about esd although this does connect to 120vac so maybe some issues may have come from there.

As far as connection order I usually turn on the board first and then connect the programmer.

I also have an olimex programmer i may try but I was having some issues with code composer.