CCS/MSP432P401R: Microcontroller Can't Run Application Code without the Debugger (MSP-FET)

After doing some troubleshooting, this doesn't have anything to do with the reset button. I merely discovered the problem after pressing the reset button caused the microcontroller to startup without the debugger.

I have an external HFXT. I'm configuring pins, bypass, enable etc for using the external crystal and then using the HFXT to source MCLK. In a debug configuration, MCLK has no issue using HFXT as a source. But it can't cycle if not in a debug configuration.

Additionally, when I try to reconnect the debugger, it has trouble recognizing the device but will eventually connect after clicking "Retry" several times.

I'm double checking how I'm changing clocks(DCO->HFXT) and using the driverlib for reference.

Hi,

I think it maybe a software problem. It maybe lies on your configuration. 

You problem is that:

1. You mean you can run you code using MSP-FET in debug mode but can make it work in free run mode. Is it right?(I must say it runs a little different in debug mode and CCS mode. )

2.  It works fine with blink LED but not with your own code. (I assumption is that this lies on your code. Maybe not CCS configuration.)

3. You need to "Retry" many times until you can connect the device after you download your problem code.(It mostly lies on hardware problem which is caused by signal distortion. It seems not on this problem. Only if you can recreate it with blink LED project.)

My advice: First, you need to make sure where the problem lies on. Can you use DCOCLK instead of HFXT to make sure if it lies on clock source.

Eason

Yes, I was able to isolate the problem by not configuring the MCLK to use the HFXT. When only using the DCO, the problem went away.

I'm trying to troubleshoot how I'm change the source for MCLK from the DCO to the HFXT. When I change the source, my application runs perfectly fine in a debug configuration, but not in free run mode. 

After attempting to run in free run mode, my debugger has issues reconnecting with the device. At first, I would just need to "Retry" several times and/or selecting "Non Debuggable Device" in the Debug Configuration menu would allow me to eventually reconnect. However, those options no longer work and I can't reconnect to the device at all.

So now I'm troubleshooting how to try to recover a possibly bricked device. Though I'm not sure what could have happened to cause that. My next step is to use my debugger on a new, second board to verify that the debugger is still working correctly.

Thank you for the suggestions!

-James

The easiest way to trigger these symptoms is to increase the MCLK speed but forget to increase the Flash Wait States. With the DCO, you have control over the MCLK speed, but the HFXT oscillates as fast as it chooses to.

This definitely makes sense with what I'm seeing. It looks like I was forgetting to copy/paste the flash wait state configuration with my clock configuration code.

I have a new board programmed, making ensure the flash wait states were also being being configured, and everything seems to be working just fine - including the reset.

A couple of follow up questions:

Is there a way to recover my device that currently can't communicate with the debugger? Or do I need to just replace the chip?

Also, the SystemInit function in the system_msp432p401r.c file that's generated by CodeComposer configures the flash wait states to 1 when the DCO is set to 48 MHz. The cs_hfxt_start.c file from the driver lib examples uses a wait state of 2 when configuring an external crystal at 48 MHz. The table in the datasheet in section 5.8 says that for VCORE1 at a frequency of 48 MHz, the flash wait state should be 1 for a normal read mode, and 3 for other read modes(program and erase verify).

If I use a flash wait state of 1, but do a program verify from CodeComposer will that harm the device? 

Thanks for help digging into these details!

Hi,

1. You mean "FET couldn't identify the target device", does it show "Error connecting to the target:Unknown device"? You say you can communicate with your device with debugger by trying "Retry" several times. It doesn't work?

2. I advice you to follow our datasheet. We don't ensure that the code download from CCS won't harm the device.

Eason

I haven't yet encountered a case where a Factory Reset didn't get me out of trouble. I have seen sporadic reports on the Forum, but not how those cases finally turned out.

I expect the debugger/downloader manages the wait states appropriately while it's running, and probably runs much slower than 48MHz.

My version of cs_hfxt_start (3.10.00.08) says

>MAP_FlashCtl_setWaitState(FLASH_BANK0, 1);

where the "1" goes directly into FLCTL_BANK0_RDCTL:WAIT [Ref TRM (SLAU356I) Table 10-14] to provide 1 wait state.

1. Yes, that's the error message that I was getting. At first, I was able to click "Retry" or change the debug configuration to include "Non Debuggable Device" and the debugger could eventually make a connection. Eventually, that stopped being the case and now I can't connect to the device no matter what I do.

2. Yep, just missed a few critical sentences in the datasheet. I was just curious if there was a way to recover the device. It's a BGA package so replacing it will take some tools that I don't immediately have access to.

Thanks!

I'll do some searching and see how to do a factory reset when the debugger can't connect to the device.

Hmm, I downloaded 3_21_00_05 (which I thought was the latest) from the TI's site, which is the one that was the easiest to find through googling. I'll make sure I have the latest version.

Thanks!

The trick with the Factory Reset sequence is that it doesn't try to connect to the device, only to the DAP (Debug Access Port) which gives it access to the mailbox registers. Are you following the sequence in Launchpad User Guide (SLAU597B) Section 5?

I found a copy of 3.20.00.06 on one of my machines, which also says

> MAP_FlashCtl_setWaitState(FLASH_BANK0, 1);

It seems odd that they would have changed it later, but who knows?

I tried doing Factory Reset through the DAP, as described in SLAU597B, but CodeComposer can't see the DAP as a non-debuggable core. I can see the DAP listed in "Target Configuration" and when I select "Routers" under the Debug Configurations, but it doesn't appear when I try to select "Show All Cores" so I can't run the Factory Reset script.

Hi James,

How about trying more times? Doesn't it work?

Eason

I've tried several dozens of times in a row and got the same result. That seemed like a reasonable number of times - definition of insanity and all. The problem no longer seems to be intermittent. It's repeatably not operating. 

I've since grabbed another board and started developing software on that board with no issues now that I'm ensuring the flash wait state is accounted for. I'll have to replace the MSP432 whenever I can find access to some tools for replacing an BGA.

The new issue is that my MSP-FET can't see the DAP as a nondebuggable core when I try to follow the instructions to do a factory reset - even on a board with a fulling working MSP432. I'm double checking the requirements for the DAP to make sure I didn't miss a hardware connection since I'm using a custom PCB.

Thanks!

Hi

I think the problem is that it is talk about launchpad. On launchpad it use XDS110. It is different with MSP-FET. XDS-110 can be used for all TI arm core device. But MSP-FET can be used on MSP432 and MSP430. Maybe it is the reason.

Eason

Sure. I'm using a MSP-FET to debug an MSP432 on a custom board. I don't have an XDS. Is there any reason why an MSP-FET wouldn't be able to communicate with the DAP on an MSP432? And the run the same Factory Reset scripts that an XDS would run on a launchpad?

Sorry, I can't answer your question. Actually, MSP-FET only support MSP432p4xx not MSP432E4xx. I don't know about what Factory Reset scripts is. At least I don't see about this function on MSP430.

The things is that we can't make sure whether the problem lies on MSP-FET or your MSP432. 

Can you send me your code in binary, I want to recreate your issue first.

Eason