This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP432P4111: Programs with XDS110 only once, then Error -261 Invalid response after that

Part Number: MSP432P4111

I have a custom board and am using the MSP-EXP432P4111 Launchpad board's XDS110 to program it. I removed all J101 jumpers and connected GND, 3V3, RST, TMS, TCK, TDO, TDI pins to my board.

With a new MSP432 on the board, I can connect and program code, but only once. When I try again, I get "CS_DAP_0: Error connecting to the target: (Error -261 @ 0x0) Invalid response was received from the XDS110. (Emulation package 9.2.0.00002)".

I have tried to reset to factory settings: when I right-click on the XDS110 CS_DAP_0 in the Non Debuggable Devices section, and attempt to Connect Target, I get the Error -261 and can't run the reset script.

Test Connection works.

I have changed the JTAG/SWD/cJTAG option to every option except cJTAG 2 pin mode, and have set a few fixed JTAG TCLK frequencies (various, from 100 kHz to 5.5 MHz), and still get a successful connection test and no connection on the CS_DAP_0 in the Non Debuggable Devices.

CCS 10.0.0.00010

MSP432P4111IPZ, LFX 32.768 kHz, HFX 24 MHz, LDO only

  • I have tested the Launchpad XDS110 by removing the custom board and reinstalling all the jumpers. It has no problems.

  • Also, I have a 10k pullup on SWDIOTMS (pin 94) and a 10k pulldown on SWCLKTCK (pin 95). RSTn/NMI is connected to a tact switch (NO, momentary to GND), and has a 47k pullup and 1000pF capacitor to GND.

  • Hello Donovan,

    It sounds like your code is changing the settings of Port J (PJSEL0 and PJSEL1 bits) which could be preventing full JTAG access on these pins. I would either change your code to not configure Port J or use SWD which allows access through the dedicated debug pins only. For more details, refer to the FAQ section in the MSP432P4111 SimpleLink™ microcontroller LaunchPad™ development kit user's guide.

    I searched the forum and there are several similar threads that my offer more guidance.

    CS_DAP_0: Error connecting to the target: (Error -615 @ 0x0)

    CCS/MSP432P401R: CS_DAP_0: Error connecting to the target: (Error -1170 @ 0x0) Unable to access the DAP.

    CCS/MSP432P401R: CS_DAP_0: Error connecting to the target XDS110 (Error -260 @ 0x0)

    Regards,

    James

  • James,

    Thanks for the response.

    The first time I programmed the chip (the only successful attempt), I used the SWD/UART mode. That was the first mode I used on the next programming attempt (which failed).

    Also, I don't think I've set Port J at all, although I'm not certain what syscfg has done. However, this does "feel" like the right direction, since it works when it's blank and then fails after the first write. I can add a pullup/down on TDI, and/or TDO, if you think that might help.

    e2e.ti.com/.../474628 (the Error -615 one) refers to e2e.ti.com/.../431666 which is an older Launchpad board and seems to add TDO and TDI pins. That's already brought to the J101 jumper block on the red Launchpad board. I connected those pins.

    (still re: 431666) Am I correct in thinking that if I connect RSTn/NMI, SWDIOTMS, SWCLKTCK, TDI, and TDO, I should be able to use all JTAG and SWD 2 and 4 wire modes?

    (re: 431666) I don't know what "Use SWD Mode with SWO Trace disabled" corresponds to in the latest CCS version, but I have tried to connect to the disconnected XDS110 using JTAG, SWD/UART, and SWD/TDO modes (View | Target Configurations, right-click, Launch, right-click, Show All Cores, right-click CS_DAP_0, Connect) -- in all modes I get the same Error -261 message. Unfortunately, there's no description in that question of how they got it working eventually, but they did.

    Question 474628 also refers to e2e.ti.com/.../1705702 which suggests importing a new project from Resource Explorer and trying the reset process. I imported the out-of-box code, and tried to reset. It failed at the same CS_DAP_0 Connect step, with the same Error -261. Just to verify, I disconnected my board and reconnected the jumpers, and was able to load and run the out-of-box example. Then I switched back and got the same errors (both for the reset process and for trying to debug normally).

    The link to e2e.ti.com/.../865406 was a little screwy, but I dug out the relevant part of the URL. That's the one with Error -1170.

    (re: 865406) The suggestion to use SWD in preference to JTAG is noted.

    (re: 865406) I've tried various clock frequencies, at random (100 kHz - 5.5 MHz range). I had seen the reference to software-dl.ti.com/.../emu_xds110.html before, and had done a few things in there. The xdsdfu -e command says it's in runtime mode. (The new location is C:\ti\ccs1000\ccs\ccs_base\common\uscif\xds110 now, not c:\ti\ccsv8\...)

    e2e.ti.com/.../1786284 wasn't much help. The reset steps were in the user guide, and I have followed them frequently through these tests.

    e2e.ti.com/.../585798 (Error -260) points to the JTAG troubleshooting document software-dl.ti.com/.../ccsv7_debugging_jtag_connectivity_issues.html which I've gone through, not thoroughly.

    (re 585798) This question also mentions swapping out USB cables. I've used a few different ones. I have a couple more brand new cables I can try. I'll do that soon.

    Sorry for the lack of brevity,

    Donovan

  • I don't think I mentioned this, but if I program the Launchpad's MSP432P4111 with the same code, I don't have a problem connecting and reprogramming.

    So I think it must be hardware differences. However, I am currently using a custom board with only the MSP432P4111, decoupling capacitors, 24 MHz crystal on the HFXT and 32.768 kHz on the LFXT, and the connections for 3V3, RST, TMS, TCK, TDO, TDI. Nothing else is populated, so all other pins are unconnected. After I started troubleshooting this problem, I added a pullup resistor for SWDIOTMS and a pulldown resistor for SWCLKTCK, but those were not designed into the custom board because the Launchpad board doesn't seem to have pullup/down resistors on those pins.

    The main difference between the custom board and the Launchpad board is that the custom board is set up for LDO-only operation. There is no inductor connected to VSW. The VSW pin is sitting at 3.3V, steady.

    Other than the VSW inductor and the HFXT crystal frequency, everything else around the MSP432 looks the same as the Launchpad schematic.

    My code has a syscfg with the Power driver set up with neither Enable HFXT Clock nor Enable LFXT Clock checked, so I think those don't yet have any effect (eventually I plan to use them, but the code is still set up for DCO).

    I'll be digging deeper into the hardware to see if there are any other differences, or assembly issues.

  • Hi Donovan,

    It sounds like you're making progress. Thanks for the updates.

    Donovan Balli said:
    I don't think I mentioned this, but if I program the Launchpad's MSP432P4111 with the same code, I don't have a problem connecting and reprogramming.

    This is a good data point.

    Donovan Balli said:
    So I think it must be hardware differences. However, I am currently using a custom board with only the MSP432P4111, decoupling capacitors, 24 MHz crystal on the HFXT and 32.768 kHz on the LFXT, and the connections for 3V3, RST, TMS, TCK, TDO, TDI. Nothing else is populated, so all other pins are unconnected. After I started troubleshooting this problem, I added a pullup resistor for SWDIOTMS and a pulldown resistor for SWCLKTCK, but those were not designed into the custom board because the Launchpad board doesn't seem to have pullup/down resistors on those pins.

    These are great things to check.

    Donovan Balli said:
    The main difference between the custom board and the Launchpad board is that the custom board is set up for LDO-only operation. There is no inductor connected to VSW. The VSW pin is sitting at 3.3V, steady.

    This may be an indirect hint. It's good that you've kept the VSW pin open since you're using the LDO. That said, you may be trying to operate the device in a way or mode that requires the DC/DC rather than the LDO.

    Donovan Balli said:
    My code has a syscfg with the Power driver set up with neither Enable HFXT Clock nor Enable LFXT Clock checked, so I think those don't yet have any effect (eventually I plan to use them, but the code is still set up for DCO).

    Check your AM_LDO_VCORE settings. SYSCFG could be specifying a level that's not supported by the LDO. You could try programming a very basic code example on your custom board and see if you notice any change in behavior.

    Regards,

    James

  • James,

    Thanks for the help so far. One big help is confirming things I *thought* but wasn't sure of, so I don't have quite as many variables when I am testing.

    JTAG

    I haven't checked everything yet in syscfg, but for the moment I'm assuming I have the LDO settings wrong. If that's the case, how do I un-set those settings on a custom board that has been configured incorrectly?

    I can't mass erase the chip because the reset script process fails with Error -261 at the step where I'm supposed to connect to the CS_DAP_0 Non Debuggable Device. That seems like a very fundamental step. I don't understand the JTAG process well enough to know what's happening, but the XDS110 doesn't seem to be able to override the settings and force the chip into a working mode, to reset it.

    Is it possible for a DCDC or wrong LDO setting to cause VSW to damage the chip in some way?

    OTHER TESTS

    I've tested with a second Launchpad board, with the same results, at least for the basic steps like trying to reset/mass erase, program, etc.

    I'm currently installing CCS on a Linux computer to see if that leads to any new insights.

    I have another bare PCB to install another set of minimal components on. Since I seem to be able to program a chip once, I can program the very basic register-level example first, and (I hope!) work my way up from there.

    Thanks,

    Donovan

  • LINUX TESTING

    Same results for normal debugging and for reset procedure.

    After clicking Debug, and getting Error -261 message box, I noticed that the red LED on the Launchpad XDS110 area was still lit. On Windows, the red LED blinks briefly but is off when the Error -261 message box appears.

  • James,

    Is there any chance www.ti.com/.../MSPBSL ROCKET will work when the Launchpad's XDS110 doesn't? It seems like JTAG would work before any kind of bootloader would.

    I tried dbgjtag.exe directly, but got no additional information -- it looks like the IDE is just capturing its output verbatim. Is there some way to get more detailed information about exactly what Invalid Response is coming back from the XDS110? Maybe a log mode, or a special debug version of the debugger firmware?

    Thanks,

    Donovan

  • James,

    One more pile of information:

    I enabled the debug log. For anyone reading this later, that process is (for CCS 10.0.0.00010): Help | CCS Support, which brings up a dialog with an Activity list, click on Debug Server Log, Properties, check Enable Debug Server Logging checkbox, browse to a convenient log file location and set a name (for me, Desktop and debug.log).

    Then I tried to debug the simple example (Resource Explorer example msp432p411x_pcm_01..., which just sets up all the pins and goes to sleep). It failed on my board, so I unplugged the Launchpad board and reinstalled all J101 jumpers and clicked the debug button again. It worked, and after it halted at the beginning of the code I stopped the debug session.

    On my board, the log file does this:

    0x00001FAC 129394 3  PERF I: GTI_CONNECT starting...
    0x00001FAC 129394 3 CS_DAP_0 GTI C: GTI_CONNECT( 0x0000023CE16C8640 )
    0x00001FAC 136683 3 CS_DAP_0 GTI R: GTI_CONNECT( 0x0000023CE16C8640 ) = 0xFFFFFFFF
    0x00001FAC 136683 3  PERF I: GTI_CONNECT finished:  7.288995s wall, 0.046875s user + 0.140625s system = 0.187500s CPU (2.6%)

    0x00001FAC 136683 3 CS_DAP_0 GTI C: GTI_GETERRSTR_EX3( 0x0000023CE16C8640, *0x0000005530BFDB68 = 0x00000000, *0x0000005530BFDB60 = 0x00000000, *0x0000005530BFDB80 = 0x00000000, *0x0000005530BFDB78 = 0x00000000, *0x0000005530BFDB88 = 0x00000000, *0x0000005530BFDB74 = 0x00000000, *0x0000005530BFDB70 = 0x00000000, "", 0x00000040, "", 0x00000400 )
    0x00001FAC 136697 3 CS_DAP_0 GTI R: GTI_GETERRSTR_EX3( 0x0000023CE16C8640, *0x0000005530BFDB68 = 0x00000000, *0x0000005530BFDB60 = 0xFFFFFEFB, *0x0000005530BFDB80 = 0x80000240, *0x0000005530BFDB78 = 0x00800000, *0x0000005530BFDB88 = 0x00000000, *0x0000005530BFDB74 = 0x00000008, *0x0000005530BFDB70 = 0x00000000, "", 0x00000040, "(Error -261 @ 0x0)
    Invalid response was received from the XDS110.
    (Emulation package 9.2.0.00002)
    ", 0x00000400 ) = 0x00000001

    On the Launchpad board, that part of the log looks like:

    0x00001FAC 1906060 3  PERF I: GTI_CONNECT starting...
    0x00001FAC 1906060 3 CS_DAP_0 GTI C: GTI_CONNECT( 0x0000023CE16ADB10 )
    0x00001FAC 1906452 3 CS_DAP_0 GTI R: GTI_CONNECT( 0x0000023CE16ADB10 ) = 0x00000000
    0x00001FAC 1906452 3  PERF I: GTI_CONNECT finished:  0.391352s wall, 0.015625s user + 0.125000s system = 0.140625s CPU (35.9%)

    0x00001FAC 1906452 3 CS_DAP_0 GTI C: GTI_GETERRSTR_EX3( 0x0000023CE16ADB10, *0x0000005530BFDB68 = 0x00000000, *0x0000005530BFDB60 = 0x00000000, *0x0000005530BFDB80 = 0x00000000, *0x0000005530BFDB78 = 0x00000000, *0x0000005530BFDB88 = 0x00000000, *0x0000005530BFDB74 = 0x00000000, *0x0000005530BFDB70 = 0x00000000, "", 0x00000040, "", 0x00000400 )
    0x00001FAC 1906452 3 CS_DAP_0 GTI R: GTI_GETERRSTR_EX3( 0x0000023CE16ADB10, *0x0000005530BFDB68 = 0x00000000, *0x0000005530BFDB60 = 0x00000000, *0x0000005530BFDB80 = 0x00000000, *0x0000005530BFDB78 = 0x00000002, *0x0000005530BFDB88 = 0x00000000, *0x0000005530BFDB74 = 0x00000008, *0x0000005530BFDB70 = 0x00000000, "", 0x00000040, "", 0x00000400 ) = 0x00000000
    0x00001FAC 1906452 3 CS_DAP_0 STATE I: Connection state changed to 4
    0x00001FAC 1906452 3 CORTEX_M4_0 POLL C: Firing DSP_DOMAIN_POWERED to all DSP_USER's
    0x00001FAC 1906452 3 CORTEX_M4_0 POLL C: Firing of DSP_DOMAIN_POWERED complete
    0x00001FAC 1906452 3 CS_DAP_0 GTI C: GTI_STAT( 0x0000023CE16ADB10 )
    0x00001FAC 1906452 3 CS_DAP_0 GTI R: GTI_STAT( 0x0000023CE16ADB10 ) = 0x0000000D
    0x00001FAC 1906452 3 CS_DAP_0 STATE I: Target execution state changed to STATUS_NON_DEBUG_NORMAL
    0x00001FAC 1906452 3 CS_DAP_0 STATE I: Debugger execution state changed to EVENT_DSP_HALT
    0x00001FAC 1906452 3 CS_DAP_0 STATE I: Connection state changed to 0

    I don't get much information out of the difference there. All I see is that GTI_CONNECT is called and then GTI_GETERRSTR_EX3 returns a 1 or 0. Nothing about what happens inside the connect function. So I don't think this will lead me to anything that says exactly what it's trying to do when it gets the invalid response, and what the response is.

    Donovan

  • Hi Donovan,

    In CCS, check your that the power configuration for your syscfg doesn't have things like the DC/DC selected for your custom board. You may need to enable custom power states to manually adjust them. Also, VCORE1 may not be supported by LDO mode.

    Regards,

    James

  • James,

    Looks like I'm down to assembling a new chip on a new PCB and testing minimal projects with LDO and VCORE1, or possibly using a BSL programmer.

    Are there other options you could suggest?

    Thanks,

    Donovan

  • It looks like my original test code kept the default DCDC mode. Is there a way to mass erase an MSP432P4111 if the DCDC is enabled but there's no inductor?

    Maybe I can somehow connect a 4.7 uH inductor between VSW pin 14 and VCORE pin 12 and see if that brings a board back to life.

  • Donovan Balli said:
    Looks like I'm down to assembling a new chip on a new PCB and testing minimal projects with LDO and VCORE1, or possibly using a BSL programmer.

    The MSP432 does support BSL programming. For more details, refer to the MSPBSL page. According to Table 1 in the MSP432P4xx SimpleLink™ Microcontrollers Bootloader (BSL) User's Guide, the MSP-BSL and MSP-FET support the MSP432P4xx devices. Depending on your connections, you may need the MSP-FET-432ADPTR too.

    Donovan Balli said:
    It looks like my original test code kept the default DCDC mode. Is there a way to mass erase an MSP432P4111 if the DCDC is enabled but there's no inductor?

    Yes, the BSL can perform a mass erase when the BSL password is incorrect (intentionally). Edit: I should say possibly rather than yes. If the DC/DC mode is enabled but the necessary components aren't connected, a POR may be issued or the device may show indeterministic operation (this comes from the CAUTION note on page 424 in the Technical Reference Manual).

    Donovan Balli said:
    Maybe I can somehow connect a 4.7 uH inductor between VSW pin 14 and VCORE pin 12 and see if that brings a board back to life.

    That's a good idea. If you do, make sure to also add a larger capacitor than what's required for the LDO mode. Before doing this, you may want to confirm that you have the recommended CVCORE value for the LDO mode on your custom board. See 5.4 Recommended External Components in the datasheet for the recommended ranges. Also, CDVCC should be larger than CVCORE. Even if this isn't causing your issue, it's still important and recommended.

    Regards,

    James

  • Here's another idea. You could try lowering the XDS110 supply voltage to 1.8-V in CCS and see if you can program your custom board since it should switch to LDO mode.

    In 8.3.1 DC/DC Regulator Care Abouts in the TRM, it mentions that the DC/DC operation automatically switches to the LDO when VCC drops too low for the DC/DC to remain more efficient than the LDO.

    The XDS110 debug probe can be used for debugging targets across 1.8-V to 3.6-V IO levels. The XDS110 probe can also be used to supply power to targets with 1.8-V to 3.6-V IO and with current draw limited to ~400 mA. Configuring the power supply capability requires some additional setup steps in CCS. See the XDS110 Debug Probe user's guide for more details, specifically 3.1.2.2 CCS Setup.

    Regards,

    James

  • First, I like the way you're thinking.

    Second, I'm using the simple example that just sleeps. After changing the target configuration for 1.8V, I don't seem to be able to get the Launchpad XDS110 to adjust the voltage. I probe XDSET_VCCTARGET while trying to debug, and it stays at 3.3V. The TPS2102 power switch EN line stays low, which seems to match. Also, the XDSET_VCCOUT from the Energy Trace regulator doesn't seem to come up -- stays at 0 V.

    If I run an Energy Trace debug session, I get 3.3V on XDSET_VCCOUT. I still get 3.3V even after going into Preferences and changing the Target Connection to XDS110 and 1800 mV.

    How do I *actually* change the supply voltage?

  • I made a mistake. The XDS110 standalone debugger can adjust the output voltage, but the on-board XDS110-ET debugger seems to only provide 3.3-V unfortunately. Looking at 2.3.4 Using the XDS110-ET Emulator With a Different Target in the MSP432P4111 SimpleLink™ microcontroller LaunchPad™ development kit user's guide, it says "the XDS110- ET outputs only 3.3-V JTAG signals. If another voltage level is needed, the user must provide level shifters to translate the JTAG signal voltages".

    That would have been a good check, but I'm sure that's why you're measuring 3.3-V even when the settings are for 1.8-V.

    Regards,

    James

  • Rats. I really liked that idea.

    I may be able to dig up a suitable level shifter and hack it in between the boards.

    But first, I'll see if a new chip can be programmed with simple LDO-only code. And I'll get a BSL programmer and try it out anyway. And try to hack in an inductor to get the DCDC mode working temporarily.

    Thanks a lot for all the help so far.

    Donovan

  • I finally was able to test a new chip on a board with minimal components, and it works normally for me.

    I still need to verify it, but the code I put on the board is probably the main issue. And it's probably the LDO-only board layout that led to the chips not talking. I'll admit that's a surprise to me -- I wasn't expecting to be able to put the chip into a mode that JTAG couldn't get it out of. It seems like the XDS110 should be able to hold the chp in reset and avoid any of my incorrect settings.

    I'll report back once with anything else I find out, so anyone else reading this in the future can benefit.

    Donovan

  • Hi Donovan,

    Again, nice progress and thanks for the updates. Let us know what you find out!

    Regards,

    James

  • I got a 4.7 uH inductor, same part number as on the Launchpad board, and tacked it in, between pins 14 VSW and 12 VCORE. Now I'm able to debug properly.

    LESSON LEARNED

    In all future boards that are meant to be LDO only, I will include a footprint for the inductor, just in case I accidentally program the wrong power options at some point. Or at least I'll bring out pin 14 VSW so it will be easy to tack on an inductor for long enough to get the chip working again. And maybe keep a few of these inductors, too.

    Your alternate approach *that I haven't tried yet* is to use an actual XDS110 rather than the Launchpad version, which will be able to drive a lower supply voltage, which should cause the chip to automatically disable the DC/DC. If that works, I won't need an inductor, I'll just need to remember to drop the voltage if the DC/DC gets re-enabled in the power settings somehow.

    I still find it very strange that the XDS110 can't hold the chip in reset and keep it from running the init code that sets the power registers. The default reset value on this chip is AM_LDO_CORE0. I guess the SWD doesn't run while the chip is in reset, and doesn't start fast enough to keep the chip from getting into DCDC mode. If so, maybe another option is to keep the chip in LDO mode for a few seconds after reset -- this seems hard to make work in a typical application.

    Maybe you can hold this question open for a week or so, until I can test the XDS110, so anyone reading this in the future can see those results also. Or maybe you could pop an inductor off a Launchpad board and test with an XDS110 quickly?

    Thanks very much for the help,

    Donovan

  • Hi Donovan,

    Donovan Balli said:

    I got a 4.7 uH inductor, same part number as on the Launchpad board, and tacked it in, between pins 14 VSW and 12 VCORE. Now I'm able to debug properly.

    LESSON LEARNED

    That's awesome work and great to hear!

    Donovan Balli said:
    Your alternate approach *that I haven't tried yet* is to use an actual XDS110 rather than the Launchpad version, which will be able to drive a lower supply voltage, which should cause the chip to automatically disable the DC/DC. If that works, I won't need an inductor, I'll just need to remember to drop the voltage if the DC/DC gets re-enabled in the power settings somehow.

    For any new boards and devices, you can just program them with your updated code that doesn't use the DC/DC mode. That should fix everything for those boards and allow you to debug them. For the existing boards that have already been programmed with the code that uses the DC/DC, then adding the inductor and larger decoupling capacitor should allow you to reprogram those boards with code that does NOT use the DC/DC. Then, you wouldn't need to keep the inductor on those boards either. If your code doesn't require the DC/DC mode, the device can function fine using the LDO mode.

    Does that make sense?

    Donovan Balli said:
    I still find it very strange that the XDS110 can't hold the chip in reset and keep it from running the init code that sets the power registers. The default reset value on this chip is AM_LDO_CORE0. I guess the SWD doesn't run while the chip is in reset, and doesn't start fast enough to keep the chip from getting into DCDC mode. If so, maybe another option is to keep the chip in LDO mode for a few seconds after reset -- this seems hard to make work in a typical application.

    I think I added some confusion here by forgetting there are two types of XDS110 debuggers: on-board and standalone. The standalone XDS110 should allow you to adjust the supply voltage similar to how our MSP-FET can do that. The on-board XDS110 is a cheaper and more convenient alternative to the standalone XDS110, but it is less configurable and can't adjust the supply voltage. If you change your code to use LDO mode and you can debug the device with the onboard XDS110, then you don't need to purchase a standalone XDS110.

    The instability of the device when configured in DC/DC mode but without the proper external components seems to be enough to interrupt or prevent the JTAG communication and functionality.

    Donovan Balli said:
    Maybe you can hold this question open for a week or so, until I can test the XDS110, so anyone reading this in the future can see those results also. Or maybe you could pop an inductor off a Launchpad board and test with an XDS110 quickly?

    Unfortunately, I am still working from home and while I have a LaunchPad, I don't have access to soldering equipment to make this change. Also, I don't have a standalone XDS110.

    For the thread status, I'll switch it to "Waiting for Customer" which temporarily closes it but allows it to reopen when you reply. I think you have around 2 weeks before it locks permanently.

    To summarize, I'd change your code to use LDO mode, and that should get your development back on track without having to add the inductor on your board or purchase a standalone XDS110.

    Regards,

    James

  • James, I won't have a chance to test the XDS110's low-voltage mode, to force LDO operation, within the next few weeks. So I'll mark this as solved. Thank you very much for all the assistance. -- Donovan

    Brief summary, for future readers who don't want to read back through the history here:

    • I designed a custom board with MSP432P4111 without an inductor on VSW, intending to use it only in LDO mode.
    • I successfully programmed the chip with a version of software that used some DC/DC power modes. That is, I kept the Resource Explorer sample code's SysCfg settings that were used on the LaunchPad board.
    • I could not re-program the chip after that, using the LaunchPad's on-board XDS110. The DC/DC power mode prevents programming, when the hardware does not support the DC/DC.
    • I temporarily connected an inductor from VSW to VCORE, and was able to re-program the chip.
    • Future software needs to have LDO-only power modes configured before being programmed onto a custom board without a DC/DC inductor. It is possible a standalone XDS110 would be able to force LDO mode, but the on-board XDS110 is not capable of this.

    Hope this helps!

  • Hi Donovan,

    First, I'm very happy to hear your issue has been resolved. You did most if not all of the work. Second, thank you for being so diligent with updating and sharing details in the thread. I know this will help someone else in our E2E community who may face the same issue, so we definitely appreciate it.

    Best of luck in your future development!

    Regards,

    James

**Attention** This is a public forum