MSPM0l1306 Locks up with J-Link

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • MSPM0l1306 Locks up with J-Link

      Hello,

      I am developing on the MSPM0L1306 Launchpad board.

      After several erase/write cycles using the J-Link and debugging with the RTT, the MSP0l1306 locked up and will not reflash. I looked through the TI forums and it seems like this can be an issue if the NONMAIN flash section is flashed. I am not touching this section in my code.

      I have had two separate boards lock-up when using a J-link only.

      On my third board, I have only used the TI debugger and it has not locked up. I am concerned there is something wrong with the JLINK reflash algorithm that is causing this lockout.

      Question: Is there some sort of recovery method for this chip that I can use with the JLINK? If I could write a script to do a mass erase or some sort of security reset that would be great if I could gain SWD reflash access again.

      Toolchain: arm-none-eabi-gcc/arm-none-eabi-gdb 12.3 with JLink_V792h/JLinkGDBServerCLExe

      Question: In the changelog, I see an update for the MSPM0 line in version 788, but I am using a higher version so I should be good there right?

      Use case: I would like to debug with a J-Link as I would like to use the RTT protocol for logging.

      Connection attempt output on locked device. VDD is good, and it looks like it finds devices on the SWD lines, but cannot connect. (See picture attached)

      Hardware Connection: I have tested this adapter board and ribbon with some other hardware (Nordic Boards) and they are working via SWD on those boards. I have tried multiple different J-Links as well.

      Jumpers: I have only the GND and 3.3V jumpers connected. All other jumpers are removed to isolate the onboard debugger from the JLINK. (See picture attached)

      Corrective actions:

      1. I have tried switching back to the onboard TI XDS110 debugger and issued a MASS ERASE, but this fails now that the chip is locked.
      Images
      • IMG_6664.jpg

        316.51 kB, 863×1,151, viewed 154 times
      • Screenshot 2023-10-27 at 2.18.22 PM.png

        202.92 kB, 870×977, viewed 118 times
    • Hi,
      Thank you for your inquiry.
      We are not aware of any such issue.

      We also highly doubt that the issue lies on J-Link side here. Please find the reason below:
      1. The NONMAIN region has a separate flashloader which is only called when the NONMAIN region is to be programmed
      2. Programming NONMAIN with data containing an invalid CRC checksum will lead to abort of programming.
      3. MAIN & NONMAIN flash regions are protected by different registers:
        - MAIN: CMDWEPROTA & CMDWEPROTB
        - NONMAIN: CMDWEPROTNM

      If the devices are indeed locked by programming NONMAIN with problematic data,
      this would mean that the J-Link was told to program it and that the data had a valid CRC value.

      Please note, that NONMAIN changes only take effect after a power-cycle of the device.
      This would explain why the effect shows "sometimes" but not always.

      If you send us a data file (.elf/.hex/.bin/...) with a sample application this issue is re-creatable with,
      we can have a quick look at it.
      Could you please also tell us which device revision you are working with (PG1/PG2)?

      Best regrads,
      Fabian
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/

      Or you can contact us via e-mail.
    • Attached is a picture of the part. TI told me it was a production revision. I read some of the pre-production revisions had issues.

      I have attached a demo hex and the linker script (change extension from .txt to .lds)
      Images
      • ti mspm0 part number.jpg

        100.06 kB, 213×176, viewed 57 times
      Files