CCS/MSP432P4111: Lost emulator connectivity to target

Hi BIt_Banger,

I am unable to see the message you tried to share. Please reupload the error message.

Which power state is the MSP-FET in? VCC_Output or VCC_Sense?

If you're using VCC_Sense, what is the target voltage setting set to in CCS and have you measured this voltage to confirm? 

If you were unable to do a factory reset without a password, see this post  and follow Dennis's instructions to use SWD to perform a factory reset. This starts from where he says "If this does not work...and you get an error message..."

BR,

Seong

Hi Seong,

I'm not sure how to check the power state on the MSP-FET, I've used whatever the default setting is, but the target voltage is 3.3V, and I've measured it.  I've loaded and ran code hundreds of times with no problem, just four builds have bricked four targets.

The Launchpad was bricked by the on-board XDS-110, and I went through Dennis's instructions, including the second part, "if this does not work..", with no luck.

Note that I bricked the Launchpad after a "mass erase" operation.  When I do a "test connection", whether in JTAG mode or SWD mode, I get the same error message:

Note that I'm running Code Composer 9.2 on a Windows 7 Pro operating system.  I doubt that's an issue, because until I manage to brick a target I can build, download and emulate no problem.  Dennis's explanation that the JTAG pins can be remapped to inadvertently brick a part is helpful, I just need to find a way to unbrick it.  Thanks.

I also noticed that when I look at the "advanced" tab of the XDS-110 emulator properties under "target configurations" I see a list of parameters under "Connection Properties", the last of which verifies I'm in SWD Mode, so I should be able to connect, but I'm not.  The target configurations that come with the examples for the Launchpad all seem to have this setting, which makes sense to prevent users from bricking boards.

When I look at the "advanced" tab of the MSP-FET emulator properties the "Connection Properties" field is blank, and the "Test Connection" button is disabled, yet I'm still able to connect when I invoke a debug session.

How do I populate the "Connection Properties" field on the MSP-FET so I can be sure I'm in SWD Mode?

Thanks.

Update:

I think I was able to assign SWD mode to the MSP-FET by copying the following code from the XDS-110 "source" tab into the MSP-FET:

<property Type="choicelist" Value="2" id="SWD Mode Settings">

<choice Name="SWD Mode - Aux COM port is target TDO pin" value="nothing"/>

</property>

It now shows up in the MSP-FET "Connection Properties" field, but I was still unable to connect.

Hi Bit_Banger,

I've consulted the subject matter expert and learned that the MSP-FET is an MSP430 and does not have SWD. Apologies for the misdirection. Also, the MSP432 is a lot more power-demanding than the MSP430, so the XDS110 debug probe should be used over the MSP-FET.

We've learned in the past that devices are more proned to be bricked from using the device's JTAG pins, because they are muxed with other signals. The SWD pins are not, so I recommended using the XDS110 + SWD.

If you didn't have issues before where you flashed your code hundreds of times, and you are now seeing this behavior tells me that something in your code may be what is causing this.

Let's focus on using the P4111 LaunchPad first, since we know that this is a more reliable board design. Here are a few things you can try:

1. Error -260 means that there is a host communication error between the host and xds110. See here.
2. Hardware Checklist
3. #9 under the "Troubleshooting connect phase" section

BR,

Seong

Hi Seong,

The Launchpad issue seems to be caused by a PC-side driver issue, since I took it home and was able to connect using a Windows 10 PC.  Note that I was able to connect on a Windows 7 machine here, but now I'm not, so something must've gotten corrupted in the XDS110 software drivers.

Thanks for the info on the MSP-FET not having SWD.  I believe the software that bricked the boards on the MSP-FET incorrectly mapped one or more of the JTAG pins, which would explain the loss of connectivity.  Once I established a stable pin mapping at startup in my code I haven't lost connectivity since.

I was not aware that the MSP432 was a lot more power demanding than the MSP430.  That would stand to reason based on the added capabilities of the MSP432, but can you provide more information on the comparison between the power draw of each part?  We are a power sensitive application porting from the MSP430 to the MSP432, so it's important that we fully understand the impact on power draw.

Thanks.