MSP430G2553: Issues with MSP-FET SBW at 2.2V

LP on 3.3V can not be used for flashing target device on 2.2V by SBW without logic level adjustment between master and target SBW lines. It can work but it is out of specification for sure, and not good for device powered by lower voltage.

MSP-FET is with faster line switching than LP (as master), than in some cases it doesn't work even LP (as master)  working fine. Maybe total capacitance on RESET pin of target device is too high for MSP-FET (SBW).

Customer target is pulling reset to 2.2V via 10k (no capacitance to speak of).  In one case, I modified that to 47k.  Our interface is pulling 47k to 2.2V and I've tried 100pF and 1nF (based on suggestions in various docs).  Again, the actual waveform edges look ok.  The only thing I noticed was changes in the bi-directional line where it looks like one side 'releases' and the other side isn't driving yet; so there is—what looks like—an RC ramp.  Pullup, capacitance and slow,medium,fast speeds all have the expected effects on what that RC ramp looks like.  I have scope plots if that is useful.  I don't know where Vih is on either side in this scenario; so I could imagine that enough of an RC ramp could look like a signaling edge and I would expect operation at the lower VCC to make that more problematic.  

Somewhat unrelated: I also see a leakage voltage—potentially from MSP-FET pin 4 which floats around 1.5V and is loaded down to ~0.5V with the target attached.

Hi Jason,

Jason Mann said:

1) Is using the LaunchPad in the configuration described ill advised to the degree that it potentially causes run-time issues related to errant/incomplete/questionable programming or otherwise violates datasheet parameters?

This is not recommended, because the voltage is higher than VCC+0.3V.

VCC is 1.8V, but the debug pin is 3.3V. Which might make the debug pin abnormal.

Jason Mann said:

2) If waveforms are provided, could guidance be given as to what part of the signaling is 'out-of-spec'.  This part is still a work-in-progress on our end.  I'm just trying to identify the correct support channel.

I will reccommend you use a launchpad to see whether it could work firstly, make sure your MSP-FET works normal and connection well.

Jason Mann said:

I also see a leakage voltage—potentially from MSP-FET pin 4 which floats around 1.5V and is loaded down to ~0.5V with the target attached.

I test a good MSP-FET, PIN4 shoud be 0V when not connected to board.

By the way, if you want to MSP-FET power the board, you should connect PIN2 to the board G2553 VCC. Otherwise, you might require PIN4 to let board work in self-power mode.

B.R.

Sal

Jason Mann said:

I am able to replicate SBW access via LaunchPad when it it attached standalone to the 'Bed of nails' fixturing

Using the LaunchPad does appear to work as long as nothing else is touching the interface (ignoring the likely fact of internal ESD diodes being biased on, or other over-voltage related issues). 

Sal Ye said:

This is not recommended, because the voltage is higher than VCC+0.3V.

Agreed.  Could I have something written on TI letterhead to provide to my customer as a manufacturer's statement of suitability (or lack thereof)?  I'm not convinced they'll take just my word (and a forum screenshot) for it.

I can RMA the MSP-FET in question if you think it's defective.  It was procured only for this project and has not been used for anything else.  Are there perhaps multiple HW revisions of the tool?  Assuming the serial number is sequential (or prefixed with a date code) mine are "230400077" and "23040001E".  I'll interpret that as 2023 production vs. 2014 (?).  I no longer have one of the older gray units ('UIF' I think); those always seemed pretty bulletproof.

At this point, what I'm really looking for is guidance on why the signaling looks ok; but the MSP-FET tool doesn't seem to see the MSP430 part; since—as we've already agreed—using the LaunchPad in a production fixture isn't viable for a target running at 2.2V.

Would it be possible to have the email contact of an appropriate TI FAE to try to help resolve this?  I'd be happy to reverse annotate our findings into this forum post.

Sal Ye said:

I will reccommend you use a launchpad to see whether it could work firstly, make sure your MSP-FET works normal and connection well.

After some consideration, I take your point about running the MSP-FET standalone and see if that is functional (similar to the LaunchPad, since that seemed ok).

<EDIT>

Wired standalone, MSP-FET seems to ID msp430g2553 ok.  MSP-FET appears nominally functional.  Interconnect to DUT appears ok.

Post transaction, the MSP-FET appears to hold 2.2V (was configured with -z [VCC=2200]) on pin 1 (SBWTDIO).  I was giving VCC in the case that Vih was dependent on that.  Would a different spec release this line (I'm assuming it's a pullup)?  This voltage being present is causing some issues with our HW; but I can probably work around that now that I know it's there.

Additionally, SBWTDIO appears to yield ~0.7V (it may be higher, this is with system loading) from cold start on USB.

<\EDIT>

Hi Jason,

Sorry for late response. I am out of office last week.

Jason Mann said:

Could I have something written on TI letterhead to provide to my customer as a manufacturer's statement of suitability

The datasheet is the thing TI could provide to customer. I assume there is no other offical documents.

Jason Mann said:

Would it be possible to have the email contact of an appropriate TI FAE to try to help resolve this?

Could you contact your customer and get the contact window? They should have the vendor for MSP device and assigned FAE or sales for them.

Jason Mann said:

After some consideration, I take your point about running the MSP-FET standalone and see if that is functional

Let me do some test based on MSP-FET and 430 LaunchPad. I haven't test it before.

B.R.

Sal

Not a problem on the other items.  I can work that with/through them if they want to go further with it.  I get the impression that it is likely to get lost in the noise on their end—it's quite a bit out of scope for our statement of work—and I've documented in detail why they should consider using something more appropriate for their non-automated programming.

Sal Ye said:

Let me do some test based on MSP-FET and 430 LaunchPad. I haven't test it before.

Appreciate this.  I was able to get this to run with our hardware with some rework.  Specifically:

Basically, changing R2 to JMP seemed to make everything happy ('VCC_TARGET' ~2.2V).  I touched up some solder joints during this rework which were maybe not great on the initial hand build.  It's not outside of the realm of possibilities that some of the issue was just poor craftsmanship on my part.  Although—if this were the case—I'm not sure why the signaling looked ok.

SBWTDIO being present when VCC_TARGET goes away causes backfeed (probably via the IO ESD diode) in one of the ICs I used on our HW.  We've rev-ed our HW to use something more appropriate: basically with 'partial power down protection'. 

I looked at the HW schematics for the MSP-FET.  I'm not certain which HW rev I have: based on it not having a 'W' in the serial number but the product box having a 'CE' mark; I'm assuming Rev 2.5.  It looks like the IO buffers have pullups and the output side is referenced to VCC_TOOL.  It seems that—programmatically—either the FW or the driver would have to look at VCC_TARGET and disable VCC_TOOL (in some fashion); but the design appears to be VCC_TOOL centric.  This could probably be remedied if the output buffers (and pullups) were referenced to VCC_TARGET; but that would likely cause some issues for the current sense architecture.  Probably also in some other use-cases where all of the pins aren't used.

I've noticed when mspflasher SW errors out; SBWTDIO doesn't get asserted.  When it successfully connects and VCC_TARGET goes away; it stays asserted.  In this case; just based on the loading, I say asserted over pulled up just because the listed 47k shouldn't be able to source enough current to do what I see.

If this tracks and our updated HW does what is intended, then this can be closed out.