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.

MSPM0L1306: MSPM0L1306 becoming permanently inaccessible after flashing

Part Number: MSPM0L1306
Other Parts Discussed in Thread: SEGGER

Hello

I am using the production version of the MSPM0L1306, flashing the device with firmware is extremely unstable. I am using a J-Link with J-Flash / Ozone. Programming an empty device is working fine but once a firmware is running it is impossible to overwrite the firmware without a full chip erase first. If no full chip erase is performed before uploading new firmware the the upload will fail and the device is sometimes becoming permanently inaccessible. No communication can be established afterward and the only way to recover is to just replace the chip.

This is the error I get when trying to flash a device that already has firmware on it:

Device "MSPM0L1306" selected.
Found SW-DP with ID 0x6BA02477
DPIDR: 0x6BA02477
CoreSight SoC-400 or earlier
Scanning AP map to find all available APs
AP[2]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x84770001)
AP[1]: MEM-AP (IDR: 0x002E0001)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xF0000000
CPUID register: 0x410CC601. Implementer code: 0x41 (ARM)
Found Cortex-M0 r0p1, Little endian.
FPUnit: 4 code (BP) slots and 0 literal slots
CoreSight components:
ROMTbl[0] @ F0000000
[0][0]: E00FF000 CID B105100D PID 000BB4C0 ROM Table
ROMTbl[1] @ E00FF000
[1][0]: E000E000 CID B105E00D PID 000BB008 SCS
[1][1]: E0001000 CID B105E00D PID 000BB00A DWT
[1][2]: E0002000 CID B105E00D PID 000BB00B FPB
Connected to target device.
ResetTarget() start
DAP initialized successfully.
ResetTarget() end - Took 5.01ms
Elf.GetBaseAddr(); // returns 0x0
Target.ReadU32 (0x00000000); // returns 0x4, data is 0x20000490
Target.SetReg ("SP", 0x20000490);
Target.ReadU32 (0x00000004); // returns 0x4, data is 0x18D
Target.SetReg ("PC", 0x18D);
J-Link: Flash download: Bank 0 @ 0x00000000: 1 range affected (32768 bytes)
J-Link: Flash download: Total: 0.494s (Prepare: 0.035s, Compare: 0.068s, Erase: 0.152s, Program & Verify: 0.220s, Restore: 0.016s)
J-Link: Flash download: Program & Verify speed: 145 KB/s
Elf.GetBaseAddr(); // returns 0x0
Target.ReadU32 (0x00000000); // returns 0x4, data is 0x20000B48
Target.SetReg ("SP", 0x20000B48);
Target.ReadU32 (0x00000004); // returns 0x4, data is 0x1B1
Target.SetReg ("PC", 0x1B1);
Programming failed @ address 0x000018D4 (block verification error)

This is the output after the device is permanently inaccessible:

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
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.

Is this a known issue?

  • Hi Luca,

    Have you try factory reset to recover the chips from the inaccessible situation?

    When it is failed to achieve a full chip erase, it may be inaccessible due to the NONMAIN flash data broken.

    Can you share more details about your hardware environment: J-Flash version, firmware package size, and have you modify any data in NONMAIN flash?

    B.R.

    Sal

  • Hello Sal

    Even with the connect under reset option, the chip remains inaccessible.

    I am using the latest release of the Segger firmware package. J-Flash is on version 7.88i. The firmware I am trying to flash is around 30KB.

    I did not try to modify the NONMAIN section.

    Maybe one thing that could be important is that I disable the reset pin in my firmware, this however did not seem to have an effect while the chip is running. I can still connect to it and perform a chip erase, only when I try to write firmware to a chip that already has firmware running it can become inaccessible. I needed to replace 3 MCUs yesterday, the problem is repeatable. 

  • Hi Luca,

    When do a erasing operation, NRST pin is not work. I am not sure the logic of J-Flash loading the firmware, maybe you can watch the RST pin signal of J-Link, and see whether there will be some signal changing.

    Meanwhile, have you try CCS with XDS110 to connect device, maybe it can work and worth to try.

    If there are any updates, please let me aware of.

    I will use my board to replace this issue based the specific environment, and try to figure out what makes it happen. It is expected to give you the feedback tomorrow or later.

    B.R.

    Sal

  • Hello Sal

    I ordered a XDS110 and will create a ticket on the Segger forum to see if other experience the same issue.

    Reproducing the issue is quite simple. All you need to do is upload a large hex file (around 30KB or bigger) with the J-Link (J-Commander) and then upload another hex file (or the modified hex file) to the device. The upload will always fail because of some data mismatch. At this point you should stop, reboot the MCU and do a full chip erase, otherwise it can become inaccessible when trying again to upload without a chip erase. 

    Best regards,

    Luca

  • Hi Luca,

    Sorry for the late response. How about your issues right now?

    I have tested based on yout comments, I loading two different hex file into device by J-Flash, and it success(34kB, and 50KB images).

    I think it is relevant to your project settings, following screenshots is my recommendation:

    Then, choose production programming for loading hex file:

    By the way, I am using the latest SDK (1.10) for test. If it still maintan the issue, maybe you can try the latest SDK and find whether it works.

    Hope it is helpful for your case.

    B.R.

    Sal