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.

MSPM0G1106: MSPM0 unresponsive after flash

Part Number: MSPM0G1106
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hi,

We are currently trying to implement a MSPM0G1106 into our design. The device is connected via I2C with our main MCU.
We are using MSPM0 SDK 2.4.0.06, SysConfig 1.21.1 and TI-clang 4.0.2 LTS.

We are required to change the I2C address for the BSL since there's already another bus device using the default I2C address of 0x48.
We also want to read the application version via the BSL requiring us to set the corresponding values in the configuration NVM.

We have the following settings in our sysconfig:

NONMAIN.nonmainWarning  = true;
NONMAIN.bslAppVersion   = 0xC0;
NONMAIN.i2cSlaveAddress = 0x50;

Flashing the device via our J-Link seems to work fine once but after attempting a 2nd flash the flash fails and results in the device being complete unresponsive. Only the application code was changed for the 2nd flash, the BSL config hasn't been changed.

The following error is reported during flashing:

CORTEX_M0P: Trouble Writing Memory Block at 0x41c00100 on Page 0 of Length 0x58: Flash download failed! ...
CORTEX_M0P: File Loader: Verification failed: Target failed to write 0x41C00100
CORTEX_M0P: GEL: File: XXXXXXXXXXX.out: Load failed.

Now only the following is reported when attempting to connect to the device:

Device "MSPM0G1106" selected.


Connecting to target via SWD
Found SW-DP with ID 0x6BA02477
DPIDR: 0x6BA02477
CoreSight SoC-400 or earlier
Scanning AP map to find all available APs
AP[0]: Stopped AP scan as end of AP map has been reached
Iterating through AP map to find AHB-AP to use
Attach to CPU failed. Executing connect under reset.
DPIDR: 0x6BA02477
CoreSight SoC-400 or earlier
Scanning AP map to find all available APs
AP[0]: Stopped AP scan as end of AP map has been reached
Iterating through AP map to find AHB-AP to use
Could not find core in Coresight setup
Found SW-DP with ID 0x6BA02477
DPIDR: 0x6BA02477
CoreSight SoC-400 or earlier
Scanning AP map to find all available APs
AP[0]: Stopped AP scan as end of AP map has been reached
Iterating through AP map to find AHB-AP to use
Attach to CPU failed. Executing connect under reset.
DPIDR: 0x6BA02477
CoreSight SoC-400 or earlier
Scanning AP map to find all available APs
AP[0]: Stopped AP scan as end of AP map has been reached
Iterating through AP map to find AHB-AP to use
Could not find core in Coresight setup
Cannot connect to target.

Trying to use the DSSM Factory reset tool with a XDS110 doesn't work. Neither do the JlinkScripts from this thread e2e.ti.com/.../mspm0l1305-dssm-commands-to-factory-reset-without-xds110 with our J-Link.

This happened with 2 out of 2 devices.

While I do understand that misconfiguring the NONMAIN region may brick the device I'm a bit confused to why it is happening in this instance.
Are we missing something? Is there any chance to recover the devices?

  • Hi Pascal,

    Just want to check the process for change nonmain:

    Does you use our example in SDK to change nonmain?

    Nonmain region will be calculated when MCU power on, thus if you just change the region you want, but not change the CRC value, this will cause error.

    By the way, if you already enable erase Nonmain region in CCS?

    Thanks!

    Best Regards

    Johnson

  • Hi,

    I think our project is based on the empty example from the SDK. We're using syscfg to change the config. So we shouldn't need to calculate the CRC manually.

    The erase selection in CCS for main/nonmain doesn't seem to exist when using J-Link.

    I got a 3rd device in the meantime and only using a XDS110 seems to work without bricking the device. Even with rewriting the nonmain section. While I did get a "DeviceInit failed. NONMAIN corrupted. Resetting to default" message once or twice while using it (I sadly didn't save the exact message) the device remains responsive.

    I guess the issue is somehow caused by the J-Link then.

  • Hi Pascal,

    Have you tried upgrade J-link driver in CCS?

    And actually, CCS will not upgrade driver automotive, need below flow to update J-link:

    https://kb.segger.com/TI_Code_Composer_Studio

    Thanks!

    Best Regards

    Johnson