LP-MSPM0G3507: -6305 error when programming

Hi Alan,

Have you tried putting the device into BSL mode, as described in this post? If not, I would suggest you try it a few times. It can be hard to time correctly but in the past when I've had the same issue unexpectedly this has fixed it for me. Usually I press and hold the two buttons to enter BSL mode as I hit the flash button, which normally results in the right timing. If you are unable to do get this to work, you may have to try other things.

You haven't edited nonmain and are seeing this? When you used sysconfig to flash the device, what debug security policy settings were you using?

Section 3.5.1 of CCS for MSPM0 MCUs describes how to perform a mass erase or factory reset, and has more information about the "editing nonmain" issue. You can try this if the other attempts have not worked. 

We have other instructions on unlocking a locked device at the bottom of this page.

Beyond this, if you've actually edited nonmain to require a password, and disabled SWD, mass erase, and factory reset are all disabled, you won't be able to unlock your device without the password.

Dylan

Thanks for the suggestions:

- I've tried to enter BSL mode by pressing SW1 during reset (both power cycle and reset button), and then trying to trigger the flash operation within 10 seconds.  I've tried a few times varying the timing, order of operations and use of curse words but nothing seemed to have any effect.

- I haven't edited NONMAIN.  My SYSCONFIG settings don't have anything added under the "Configuration NVM" page, so I assume the Debug Security Profile is unchanged from the default (lowest?).

- I'm using Theia so the instructions in section 3.5.1 don't look quite like what I'm using.  However, I think from the description that the tool I linked in my original post to use the Debug Subsystem Mailbox should have done the same thing - while it claimed to have completed without errors it doesn't appear to have changed the outcome.

The further instructions for unlocking a device appear to be variations on the above, and they don't seem to have helped.  I don't think the preventative actions are mostly relevant as I wasn't using sleep modes beyond WFI, and the LP board keeps access to the BSL trigger lines.

I haven't edited NONMAIN to require a password.  How easy is it for this to happen by accident?  I don't want to end up killing off boards due to some quirk of chance.

Alan

Alan,

Sorry these didn't work for you. And you are correct that the links I provided had some repetitive instructions. I also directed you to the instructions for a manual factory reset in case you thought the factory reset tool wasn't working properly and wanted to be sure. But you are correct that these do the same thing.

If you never edited nonmain or the debug security, that does help narrow it down a bit.

When you attempted to flash using PyOCD, this probably erased nonmain. When you do this without reprogramming it in the same access, the device becomes locked and you won't be able to access it again. Please see this post for more information.

As for what happened in the first place to give you that issue, is it possible that you erased nonmain before using PyOCD? Were you using the standalone sysconfig tool before PyOCD, or the version in CCS eclipse or theia?

I use CCS eclipse, and in there any settings that could lead to erasing nonmain that I know of are pretty well marked. Obviously I am biased here but I think it is not easy to accidentally erase nonmain. Please let me know which tool you are using. If you elaborate a bit on the steps you took before you saw this issue, I can probably find what went wrong and led to this.

Dylan

Thanks for the link to the thread about pyOCD - I hadn't seen that, but it gives me an interesting insight into how easy others have found it to brick one of these devices and why pyOCD does what it does.

However, I only installed pyOCD *after* encountering the error with my device, so I can confidently say my troubles didn't start with pyOCD.  My only access to the LP had been through the tools installed with Theia.  I had been iterating on a GCC-compiled sample application that configured TIMA0 and started it, occasionally changing the LOAD settings in an ISR triggered by the timer itself, so that I could modify the output waveform.  I think my last change had been to include an assert() function to catch a corner case I was seeing.  On each re-compilation of the firmware, Theia would detect a change in the image being debugged and offer to reflash the LP - I would choose "yes" and normally this worked fine - until it didn't.  I'm not sure exactly what happened when the failure occurred, but I wasn't really varying how I was using the tools.  I have logic analyser probes attached to my LP, but other than that there is nothing else connected to the board.

Alan,

Thank you for providing this information. Could you also tell me the compiler version, SDK version, and CCS Theia version that you are using? Additionally, are you using a Rev. A Launchpad, or PG2.0? This would be marked on the launchpad next to pushbutton S2. I am collecting this information so that I can bring this issue up with my team so we can investigate the issue more thoroughly. Clearly you are not the only user who has experienced this issue. Thanks

Here's the version information you're after:

CCS Theia: 1.1.0
Compiler: GNU v9.2.1 (Linaro)
MSPM0 SDK: 1.20.0.05
SysConfig: 1.18.0
Launchpad: Rev A

In case it's significant, the debug adapter on my board also told me in the last day or so that it needed an update, although I'm not sure how to find what it went to and my board definitely worked for a while after the update happened.

Okay Alan thank you for the info here. I can update this thread when we've looked further into it. Someone on the team has suggested deleting the debug configuration that you are using and trying to generate a new one to program it with. I haven't verified this yet but you may want to try it.