MSP432 Programming conundrum.

[Nitrousoxide]

Hello, people of the internet.

I have run into an issue related to programming an MSP432 on a production board, it passes the JTAG test but then fails to program.

Context: The MSP432 is on a board with several buck converters and motor drivers, none of the external devices are active except for the buck converters. The whole purpose of the device is to run an automated control system. The MSP432 is being programmed through the use of CCSv7 and an XDS110 debugger on an MSP432 launchpad board.
Programming the development board works as intended but once the production board is used as a target, issues being to arise.

Issues: Conducting the JTAG test inside of CCSv7 yields the results of "The JTAG IR Integrity scan-test has succeeded." and "The JTAG DR Integrity scan-test has succeeded.". But once I attempt to program the target with a blank project, CCS produces the error:

"Error connecting to the target:
(Error -1170 @ 0x0)
Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK).
(Emulation package 7.0.48.0)"

After some initial googling, I found there was a procedure to hardware reset the device. I attempted to do so and reach an error:

"Trouble Writing Register DP_RESET:
(Error -1170 @ 0x2)
Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK).
(Emulation package 7.0.48.0)

No connection possible. This could be caused by the device having gone to low power mode and disabling JTAG PINs.
You have the option to either toggle reset or try to use SWD instead."

This has been tested with a JTAG clock of 1MHz and 500kHz and both yields the same result.

Following the advice, I have tried to use SWD with AUX COM as TDO pin.

This produces an error:

"Error connecting to the target:
(Error -613 @ 0x0)
The target indicates that it is busy.  Either try the SWD request
again, or abort the transaction.
(Emulation package 7.0.48.0)"

Question: This leads me to believe that the MSP432 itself is somehow stuck in a software loop? I thought that the JTAG has some form of hardware priority over the processing core as it is an external peripheral. Is it possible to revive this seemingly bricked MSP432? Is there a critical design error that somehow allows a JTAG test to pass but then a subsequent programming attempt to fail?

To cover all my bases, I have attached an image of the local parts around the MSP432 (Yes, I know the placement is horrendous but this is one of my first boards so please be gentle). P9 is the JTAG header.



My only comment is that I have not populated an external oscillator, DOCR resistor or an inductor L1 (I am assuming it will operate in DC-DC mode, assumptions are naughty, I know).

I have tested the 3.3v rail and it is present.

I will also attach a photo of my setup: (to prove that JTAG wires are not too long)



I've been beating my head against the wall with this issue as I cannot come to a solution. Any words of advice at all would be appreciated.

[Fred27]

I'd compare the design of the launchpad with your own. The LP should have minimal external components to get the MSP432 to run. If it's there then there's probably a reason for it. Have you missed something like a pull up resistor on a reset pin?

[andyturk]

I've got no particular advice about MSP432, but one bad thing that can happen in an unreliable programming attempt is the mcu is programmed "enough" to screw up the GPIO configuration and disable the SWD/JTAG pins. If that's what's happening, you'll need to reset the device and catch it before it starts to execute the bad code. Then you can wipe flash completely and start over.

Are you able to use SWD/JTAG on a fresh production board with a never-before-programmed mcu? If you get the same error on a new board, it's probably a hardware issue.

[Nitrousoxide]

I'd compare the design of the launchpad with your own. The LP should have minimal external components to get the MSP432 to run. If it's there then there's probably a reason for it. Have you missed something like a pull up resistor on a reset pin?

I've checked the recommended components, including the connections for unused pins table and have satisfied them accordingly:



Is the pulldown resistor on SWO absolutely critical for the operation of JTAG? because that's the only component that is missing. (Assuming that SWDIOTMS and SWCLKTCK are being used and do not require their pull up/downs).

I've got no particular advice about MSP432, but one bad thing that can happen in an unreliable programming attempt is the mcu is programmed "enough" to screw up the GPIO configuration and disable the SWD/JTAG pins. If that's what's happening, you'll need to reset the device and catch it before it starts to execute the bad code. Then you can wipe flash completely and start over.

Are you able to use SWD/JTAG on a fresh production board with a never-before-programmed mcu? If you get the same error on a new board, it's probably a hardware issue.

It was an example TI-RTOS program that worked perfectly on the dev board. How would one reset the device before execution starts if it has such a fast startup time?

Now that you mention it, on a revision 1.1 board I was getting the same error. I didn't think much of it because I thought it was down to user error (accidentally frying the MSP). Even if it's a hardware issue, I don't see what the issue could be as to my understanding there isn't much going on.

[Fred27]

I've no idea if the pulldown resistor is critical, but it should take very little time to kludge one in temporarily to rule it out.

[rsjsouza]

There's a reference for the error you are getting:
http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems#Cannot_access_the_DAP

Regarding the resistor, I am with Fred27 - that and the twisted and long wiring, which could cause signal integrity problems (I have experienced that happen in one of my Launchpads).

[Nitrousoxide]

There's a reference for the error you are getting:
http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems#Cannot_access_the_DAP

Regarding the resistor, I am with Fred27 - that and the twisted and long wiring, which could cause signal integrity problems (I have experienced that happen in one of my Launchpads).

After adding the pull-down resistor of 43kOhm to GND, the boundary test passes but I still get the same error as:

"Error connecting to the target:
(Error -613 @ 0x0)
The target indicates that it is busy.  Either try the SWD request
again, or abort the transaction.
(Emulation package 7.0.48.0)
"

Attached is a photo of my JTAG settings. I'm running the lowest JTAG clock speed, the boundary test passes so I assume signal integrity would not be an issue?
I have looked at the wiki page that you linked but it is very vague. Following the hardware reset procedure error again after making the modifications yeilds the same result of:

"
CS_DAP_0: Error connecting to the target: (Error -613 @ 0x0) The target indicates that it is busy.  Either try the SWD request  again, or abort the transaction. (Emulation package 7.0.48.0)

CS_DAP_0: Trouble Writing Register DP_RESET: (Error -613 @ 0x2) The target indicates that it is busy.  Either try the SWD request  again, or abort the transaction. (Emulation package 7.0.48.0)
MSP432_Factory_Reset() cannot be evaluated.
Target failed to write register DP_RESET
    at DP_RESET=1 [msp432_factory_reset.gel:44]
    at MSP432_Factory_Reset()
"

I am able to manually connect to the DAP but once attempting to run the factory reset script, the error occurs. This leads me to believe that the chip is stuck in a software loop? How would I be able to recover it?d

Another note: I can connect to the DAP successfully but once I attempt to access the memory via the memory browser, CCS times out.

[andyturk]

How would one reset the device before execution starts if it has such a fast startup time?

You'd probably have to use the reset pin and make sure the debugger grabbed control right away.

https://electronics.stackexchange.com/questions/86418/relationship-between-reset-pins-and-swd-functions-arm-cortex-m0

https://mcuoneclipse.com/2016/01/17/hardware-reset-for-arm-cortex-m-with-segger-j-link-and-kinetis-design-studio/

[Nitrousoxide]

How would one reset the device before execution starts if it has such a fast startup time?

You'd probably have to use the reset pin and make sure the debugger grabbed control right away.

https://electronics.stackexchange.com/questions/86418/relationship-between-reset-pins-and-swd-functions-arm-cortex-m0

https://mcuoneclipse.com/2016/01/17/hardware-reset-for-arm-cortex-m-with-segger-j-link-and-kinetis-design-studio/

CCS Prompts to toggle the reset pin and repeat the debug action. Viewing the reset line with the scope shows that once the button is pressed, the reset line is in fact drawn to ground. Would I need to hold it on ground?

[rsjsouza]

If you have access to the DAP, you can reset the device to factory default. The link I sent talks about an Invalid device ID error, which has posts that show how to do that. 

I have been through this before. 

[Nitrousoxide]

If you have access to the DAP, you can reset the device to factory default. The link I sent talks about an Invalid device ID error, which has posts that show how to do that. 

I have been through this before. 

I have tried to factory reset the device multiple times but it yields an error, I will show you what I mean:

In the image below, you can see clearly that I have successfully connected to the DAP:


After going to Scrips - > default -> MSP432_Factory_Reset, I receive an error of:

"
Trouble Writing Register DP_RESET:
(Error -1170 @ 0x2)
Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK).
(Emulation package 7.0.48.0)

No connection possible. This could be caused by the device having gone to low power mode and disabling JTAG PINs.
You have the option to either toggle reset or try to use SWD instead.
 "

This is with JTAG clock at 500kHz, toggling the reset line multiple times does not do anything. Could it be that I have an incorrect JTAG setting? Or do you think its a driver conflict?




After messing around with restarting device/debugger, I get this error:

"
CS_DAP_0: Trouble Writing Register DP_RESET: (Error -1170 @ 0x2) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 7.0.48.0)  No connection possible. This could be caused by the device having gone to low power mode and disabling JTAG PINs. You have the option to either toggle reset or try to use SWD instead.

MSP432_Factory_Reset() cannot be evaluated.
Target failed to write register DP_RESET
   at DP_RESET=1 [msp432_factory_reset.gel:44]
   at MSP432_Factory_Reset()CS_DAP_0: Error: (Error -261 @ 0x0) Invalid response was received from the XDS110. (Emulation package 7.0.48.0)
CS_DAP_0: Error: (Error -122 @ 0x0) A bad parameter value was detected within a function. It is likely a problem with `SC_ARGS' in SMG_call(). (Emulation package 7.0.48.0)
CS_DAP_0: Unable to determine target status after 20 attempts
CS_DAP_0: Failed to remove the debug state from the target before disconnecting.  There may still be breakpoint op-codes embedded in program memory.  It is recommended that you reset the emulator before you connect and reload your program before you continue debugging
MSP432_Factory_Reset() cannot be evaluated.
Could not write register DP_RESET: target is not connected
   at DP_RESET=1 [msp432_factory_reset.gel:44]
   at MSP432_Factory_Reset()MSP432_Factory_Reset() cannot be evaluated.
Could not write register DP_RESET: target is not connected
   at DP_RESET=1 [msp432_factory_reset.gel:44]
   at MSP432_Factory_Reset()
"

This leads me to belive this acutally could be a driver/CCS/XDS110 software conflict? I will attempt to update the debugger to the latest firmware and to re install CCSv7

EDIT: After trying to perform a boundary scan in 2-Wire advanced JTAG mode, I recieve an error of:

"
The value is '-233' (0xffffff17).
The title is 'SC_ERR_PATH_BROKEN'.
"

Which is odd since the 4 wire JTAG passes a boundary scan, and all of the pins are used in the process. Would anyone know why this occurs? Is it a hardware/layout issue?

[Nitrousoxide]

After some more research, I have come to another conclusion that whilst the DAP is accessible the core is unable to be reset. To confirm this theory I have probed the Vcore pin which leads me to another question.

The Vcore pin is reading approximately 240mV. I only have a 100nF capacitor attached to the Vcore pin as the datasheet suggests (which is smaller than the other decoupling capacitors, again as the datasheet suggests).

What is the typical Vcore I should be seeing? (This is not listed in the datasheet for some odd reason, searching the internet says around 1.2V but I would like to confirm)
Does the MSP432 automatically go into LDO mode instead of DC-DC mode?
From the components in the vicinity of the MSP432, could any of them be causing the MSP432 to lose Vcore? (I don't see anything, it is completely unloaded and only has one capacitor attached to the node).