TEST/SBWTCK tied high for MSP-TS430PZ100C w/ MSP430F5338 when FET not connected

Is there a question here? Or are you just making a statement?

Yes.We would like to ask,maybe somebody  run into this problem. Again, 

If the JTAG FET is not connected,should we tie TEST/SBWTCK PIN-91 (JTAG-Pin-8) to VCC? Currently we're working with evalution board  (MSP-TS430PZ100C ) and  MSP430F5338 as CPU. While  TEST/SBWTCK PIN-91 (JTAG-Pin-8) is not high, our setup doesn't work properly.Thanks.

I've always left TEST/SBWTCK floating and never had a problem. But I am using 55xx devices, not 53xx.

Are you in a noisy environment where the pin could be getting crosstalk on it when left open?

I tied TEST/SBWTCK to GND and that did not help. So if noise was coupling onto a floating input, this should have solved the problem.

Only if I tie this signal to VCC does my system work correctly.

Normally, TEST pin has an internal weak pulldown that turns the 4-wire JTAG port pins into GPIO pins. There is no need to pull it high, it is even not recommended. You should leave it floating when not requiring to use it for JTAG operation. So I rather guess it is catching crosstalk from other PCB traces - more than the pulldown can fight. Which is strange.

Hi All,

I know, a 9-month old thread...  MSP430F5438A in a BlueRadios BR-LE4.0-D2A Bluetooth module.

Using MSP MINI SPY-BI WIRE.

Luck would have it, that I have the same issue as Gary.

The target runs fine with a MSP-FET430UIF programmer plugged in.  _Pauses_ when I disconnect it.  _Resumes_ when I reconnect it (without any kind of reset).

• I see that with the programmer connected I get 3V on SBWTCK (and the target runs).
• With the programmer disconnected, I get ~0V on on SBWTCK (and the target _pauses_). (no output on a USB/serial monitor).
• With the programmer reconnected, I get 3V on on SBWTCK (and the target runs again). (with expected interaction on a serial monitor).

• SPY-Pin    MSP/BlueRadios-Pin   Notes
• 1               Reset Pin                     -> 47k pullup to 3V,  and a 2.2nF to Gnd (unseen in pic).
• 4               (none)                          -> connected to target's Vcc (3V)
• 7               SBWTCK                      -> direct to SBWTCK pin.
• 9               (none)                          -> connected to target's Gnd

PortJ config: PJDIR  = 0xFF;   PJOUT  = 0;

SFRRPCR is default.

A power-cycle with the programmer disconnected does not solve the problem.  Connecting the programmer after a power cycle does not result in a recovery.

Expensive graphics below.  Any ideas/suggestions welcome.

-Chris

Hi all,

I'm still struggling with this issue.  The target runs reliably with SBWTCK/TEST pulled high.  And I know this is not recommended.

It does not run when SBWTCK/TEST is pulled low.

I have plowed through slau319, and am now out of ideas.

Any suggestions?  What kinds of things can lead to this type of behavior?

I have a FT230 USB bridge tied to the UART pins... power up issues? (Power is always from USB)

Below is a table listing all of the connections to this module.

**It must be something related to this pcb, as my firmware works fine on a BlueRadios Dev board.  Microscopic examination of the Dev board and schematic resulted in no detectable differences (however.. there must be!).

I'm kinda at a loss on how to troubleshoot this, as the target also works fine when the MSP-FET430UIF is connected.

Best regards,

Chris

Power-up issues are possible. What about a capacitor parallel to the reset jumper? 2.2nF are allowed when SBW is used for debugging/program upload. If a series resistor is placed between capacitor and the RST pin/SBW connector, then a higher value can be used (100nF are common). This stretches the time between Vcc reaching brownout level and the MSP starting. Useful if VCC is rising slowly.

Note that the MSP can be powered through its port pins. If a port pin is exposed to a voltage above Vcc (especially if Vcc is 0V), current flows through clamp diodes from the port pin to Vcc. So if an input signal is active while the MSP is unpowered, this may partly power the MSP. 8remember, the MSP is low power, so the allowed maximum rated clamp current of 2mA is plenty)

However, I still don't see why leaving TEST floating or pulling it low may expose problems that do not arise when TEST is pulled high.

 I cans see that entering SBW mode would sewer the RST pin from the reset logic, preventing accidental resets due to heavy noise on the RST line. But simply pulling TEST high would enter 4-wire JTAG mode (actually switch PortJ from GPIO to JTAG) and would not affect RST. But it could be possible that noise on RST while TEST is pulled high will enter SBW mode. (I'm not familiar with the entry sequence) and this could be an explanation.
In this case, maybe the capacitor on RST will help too.

Jens-Michael Gross,

*Blueradios Bluetooth module with MSP430F5438A/CC2564*

The issue was still present when LPM3 was changed to LPM2, then finally disappeared for LPM1.

My first thought was DCO issues, as mentioned here:

http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/242805.aspx?pi283121=1

Also PMM11, PMM12 in the errata.

Adding delays in the ISR seemed to have no affect. 

I then disabled SVS and SVM (both low and high).  Now the gadget works fine with/without the FET connected, through power cycles, and recovering from LPM3.

I believe the FET was preventing  any LPM from taking hold (Test pin), and masking the issue with my SVS/SVM settings in the PMM.

I suspect transients where triggering a POR (as enabled in PPMRIE, SVSxPE).

Notice how I'm saying 'believe' and 'suspect' alot... I have yet to prove anything, other than the existence of a fault state.

I'm looking through the errata now...  I will try to thoroughly eliminate the possibility of the DCO issue next.

-Chris

Edited above post.  Added link to the DCO issue.