• State
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 89 views
  • Users 0 members are here
Support feedback
Options
Options
Related

Original question:

MSPM0G3507: MSPM0G3507 development kit unresponsive

MSPM0G3519-Q1: NONMAIN was erased?

Michael Mermelstein
Prodigy 30 points

Part Number: MSPM0G3519-Q1
Other Parts Discussed in Thread: MSPM0G3519

My XDS110 USB Debug Probe no longer programs my MSPM0G3519.

I've come to the same point as this person, with the same errors in Code Composer Studio: https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1589478/mspm0g3507-mspm0g3507-development-kit-unresponsive

CS_DAP_0: Device diagnostic read = 0x00000036

I suspect that it was caused when a debug session was interrupted during a crash of Code Composer Studio.  I have another board, and everything works on that board, so the debugger and cables are all fine.  I'd like to recover the failing board if possible. CCS suggests this sequence: "remove power, hold nRST low, connect the device while nRST is held low, and then perform a DSSM factory reset"

My question: What's the exact sequence I should use for these actions:

  • Connect the XDS110 to the host with USB
  • Tie nRST low (via a jumper to GND)
  • Connect the XDS110 to the target board with its ribbon cable
  • Power up the MSPM0 board
  • Start the DSSM factory reset script (auto? manual?) on the host
  • Release nRST (removing the jumper, allowing nRST to be pulled up to 3.3V)

That's the sequence I tried, as well as flipping the last two steps.  No apparent change.

So my next question: what diagnostic info can I get during this process?  How do I see what's going on?

My ultimate question: Is the MSPM0 really unrecoverable?

Thanks!

 

 

  • 0
    TI__Genius 14851 points

    Hi Michael,

    There is an info that we used for internal debug. Could you do the following steps and let me know the result? Thanks!7245.Read CFGAP_BOOTDIAG.pdf

  • 0 in reply to Zoey Wei
    Prodigy 30 points

    Hi Zoey,

    Thanks!

    I followed the PDF instructions.  The new CCS is a bit different.  Is there still an "expressions" window?  Anyway, I think I got the right info.  Here's a screenshot of it.

    What does this mean?

    Thanks for your help!

    Michael

  • 0 in reply to Michael Mermelstein
    TI__Genius 14851 points

    Hi Michael,

    BOOTDIAG = 0x36 means NONMAIN CRC checksum verification fails. 

    The device has been locked permanently 

  • 0 in reply to Zoey Wei
    Prodigy 30 points

    Hi Zoey,

    Thanks for translating that code for me.

    This is inconvenient in my application, since the chip is embedded into a prototype, and it will be costly and time consuming to dig it out of all the surrounding hardware in our system.  Is there a way to set up CCS so that the NONMAIN section isn't erased every time we start a debugging session?  What are the safest settings for us to use during development?  We didn't set up a (non-default) password or any of the advanced security options yet, figuring there would be a risk of bricking the part, but we still managed to trigger this failure.  I'd like to learn the best procedures and settings to avoid this inconvenience in our ongoing work with this chip.

    Thank you for all your support!

    Michael

  • 0 in reply to Michael Mermelstein
    TI__Genius 14851 points

    Hi Michael,

    That is certainly possible, and it is also advice I frequently give to customers" Please do not make any modifications to NONMAIN for the time being." Once all the other function has been developed, then add the "Configuration NVM".

    And in the project properties, do the following step to make sure you only erase MAIN region. Thanks!