MSP-FET: Cannot Connect to Target

I assume that you have gone through https://training.ti.com/debugging-msp432-using-msp-fet-debug-probe? 

You are not writing anything on how you connect the MSP-FET to your board? Is it a custom board? Do you have the full error text? 

You post does not contain a lot of information.

We tried a new emulator, and we were able to connect once to our target, but that was it.  Note that all last week I was able to connect to the same target, but I'm not having any luck now.  I get the following message:

We've tried different target boards, we've checked the cables, an external power supply using the switch on the MSP-FET_432ADPTR, different PCs, same problem.

FYI the target processor is a MSP432P4111.

Any ideas?

Thanks

The message didn't display properly:

Did you try this debugger with the older MSP430 board to verify that the debugger works with this target? 

We did try with the 430 and we had problems connecting, which tells me the code running on the target may have damaged or altered the configuration of the MSP-FET, and this is repeatable.  The same behavior happened on two different emulators with the same code and the same target. 

I was able to get the MSP-FET running on the target before, but that was with different code.

I was also able to get a Launchpad with the MSP432P4111 running the code that didn't run on our target with no problem, but that's based on the XDS100 emulator, and obviously the I/Os are different. 

All the code does is configure the pins to suit our application, aside from the system configuration that is repeated in all of the example projects.  It does not manipulate the JTAG pins.

When we looked at the Vcc Output pin to ground on the MSP-FET-432ADPTR we noticed a drop in the voltage to ~1.7V while it was trying to connect, then it would fail and return an error message, but this voltage drop could be caused by the state of the emulator, I wasn't able to test it on a healthy connection.  We tried switching the power source to provide external power with a power supply, and then we didn't notice a drop in the voltage on the output pins, but we were still unable to connect.

We've thoroughly checked the cables and verified all the signals with an ohmmeter, and we've tried new cables with the same results.

I'm tempted to try an XDS-100 emulator, but it would be nice to have some insight into what could be causing what we have to fail, like a pin that's drawing too much current or something.

Thanks.

The behaviour of the debug probe should be independent of the image you are trying to download.

You wrote "we noticed a drop in the voltage to ~1.7V ". Which pin was this measured on? 

Is this drop independent of the target you are trying to connect to (also the old 430 target)? 

There's a list of compatible debuggers in TI's "MSP432-Debuggers" web page, and when I look at the XDS-110 link (TMDSEMU110-U) it tells me it's not compatible with the MSP-430.  Does that mean it's not compatible with the MSP-432 as well?  If so, is there another low-cost recommended emulator for the MSP432 besides MSP-FET we should try?

Thanks.

The voltage measurement was made between Vcc and Gnd on the header of the MSP-FET-432ADPTR.  We also noticed the reset pin is only brought down to 1.0V when trying to connect.  That seems high.  We'll try the 430 as well.

Thanks.

If you look at http://www.ti.com/tool/TMDSEMU110-U, MSP432 is listed as supported. 

Got it, we will try the XDS-110 on our MSP-432 target, thanks.

We received the XDS-110 emulator and we still have a connectivity issue with the target boards we lost connectivity with earlier.  For reference we've been using an MSP432P4111 Launchpad, and we haven't had problems with it, so it's obviously something different on our target.  Yesterday I found a one-off issue on the pin mappings, and when I fixed it I was able to load our target repeatedly, so the problem appears to be caused by the pin mappings.  The power draw was high, so I tried the pcm_go_to_lpm3 example below, and I managed to brick another board, for a total of three targets I cannot connect to now.

It's notable that the JTAG port pins are all mapped as outputs low in the example below, but that doesn't seem to affect connectivity on the Launchpad, because I can continue to flash code to it.

Is there a way to "un-brick" my target boards?

Thanks

int main(void)

{

/* Halting the Watchdog */

MAP_WDT_A_holdTimer();

/* Terminating all remaining pins to minimize power consumption. This is

done by register accesses for simplicity and to minimize branching API

calls */

MAP_GPIO_setAsOutputPin(GPIO_PORT_PA, PIN_ALL16);

MAP_GPIO_setAsOutputPin(GPIO_PORT_PB, PIN_ALL16);

MAP_GPIO_setAsOutputPin(GPIO_PORT_PC, PIN_ALL16);

MAP_GPIO_setAsOutputPin(GPIO_PORT_PD, PIN_ALL16);

MAP_GPIO_setAsOutputPin(GPIO_PORT_PE, PIN_ALL16);

MAP_GPIO_setAsOutputPin(GPIO_PORT_PJ, PIN_ALL16);

MAP_GPIO_setOutputLowOnPin(GPIO_PORT_PA, PIN_ALL16);

MAP_GPIO_setOutputLowOnPin(GPIO_PORT_PB, PIN_ALL16);

MAP_GPIO_setOutputLowOnPin(GPIO_PORT_PC, PIN_ALL16);

MAP_GPIO_setOutputLowOnPin(GPIO_PORT_PD, PIN_ALL16);

MAP_GPIO_setOutputLowOnPin(GPIO_PORT_PE, PIN_ALL16);

MAP_GPIO_setOutputLowOnPin(GPIO_PORT_PJ, PIN_ALL16);

/* Configuring P1.0 as output and P1.1 (switch) as input */

MAP_GPIO_setAsOutputPin(GPIO_PORT_P1, GPIO_PIN0);

/* Configuring P1.1 as an input and enabling interrupts */

MAP_GPIO_setAsInputPinWithPullUpResistor(GPIO_PORT_P1, GPIO_PIN1);

MAP_GPIO_clearInterruptFlag(GPIO_PORT_P1, GPIO_PIN1);

MAP_GPIO_enableInterrupt(GPIO_PORT_P1, GPIO_PIN1);

MAP_Interrupt_enableInterrupt(INT_PORT1);

MAP_Interrupt_enableSleepOnIsrExit();

/* Starting LFXT and sourcing ACLK and BCLK from it */

MAP_CS_setExternalClockSourceFrequency(32000,48000000);

MAP_GPIO_setAsPeripheralModuleFunctionOutputPin(GPIO_PORT_PJ,

GPIO_PIN0 | GPIO_PIN1, GPIO_PRIMARY_MODULE_FUNCTION);

/* Setting LFXT to lowest drive strength and current consumption */

MAP_CS_startLFXT(CS_LFXT_DRIVE0);

MAP_CS_initClockSignal(CS_ACLK, CS_LFXTCLK_SELECT, CS_CLOCK_DIVIDER_1);

MAP_CS_initClockSignal(CS_BCLK, CS_LFXTCLK_SELECT, CS_CLOCK_DIVIDER_1);

/* Enable retention for block 0 and block 31, disable retention for

* blocks 1-30. */

MAP_SysCtl_A_disableSRAMRetention(0x20002000, 0x2003C000);

/* Disabling high side voltage monitor/supervisor */

MAP_PSS_disableHighSide();

/* Enabling "rude" mode which forces device to go to sleep regardless of

* outstanding clock requests

*/

MAP_PCM_enableRudeMode();

/* Enabling MASTER interrupts */

MAP_Interrupt_enableMaster();

/* Going to LPM3 */

while (1)

{

/* Note that while this examples just goes to LPM3, LPM4 is essentially

just LPM3 with WDT_A/RTC_C disabled. For convenience, the user can

use the MAP_PCM_gotoLPM4() function if they want the API to handle

the disabling of these components */

MAP_PCM_gotoLPM3();

}

}

/* GPIO ISR */

void PORT1_IRQHandler(void)

{

uint32_t status;

status = MAP_GPIO_getEnabledInterruptStatus(GPIO_PORT_P1);

MAP_GPIO_clearInterruptFlag(GPIO_PORT_P1, status);

/* Toggling the output on the LED */

if(status & GPIO_PIN1)

{

MAP_GPIO_toggleOutputOnPin(GPIO_PORT_P1, GPIO_PIN0);

}

}

I have been OOO, what is the latest status on this case?