• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 32 subscribers
  • Views 1322 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSPM0C1104: MCU bricked/unresponsive! Can it be reset to factory settings?

Goran Demšar
Prodigy 90 points
Part Number: MSPM0C1104
Other Parts Discussed in Thread: SEGGER,

Tool/software:

I've been trying to program my board with XDS110 debug probe (LP-MSPM0C1104 demo board) and I managed to brick the MCU.

In the CSS-Thea I was getting the following error: CORTEX_M0P: Error connecting to the target: (Error -614 @ 0x0) The target indicates there is an error condition from a previous SWD request. Clear the error the condition, and try the SWD request again. 

When I connect with the Segger flasher I get a bit more information, but communication can't be established. I've used all the samples trying to find what causes the MCU not to connect any more. If I used segger flasher on a 'fresh' device I could connect to the device few times and do some read/write/verify/...  and suddenly I couldn't connect anymore. At first I thought that changing (lowering) the communication speed caused it, but I am not certain anymore. In segger flasher I have disabled NONMAIN flash.

Did anyone came across this issue? Can the device be un-bricked? It looks like communication is possible since MCU responds with some data when it tries to connect.

Kind regards

Goran

  • +1
    TI__Mastermind 29075 points

    Hello Goran,

    Someone else was having this issue and I was assisting them in this E2E thread here: https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1369697/lp-mspm0c1104-not-able-to-flash-or-erase-the-launchpad-mcu 

    Please follow the steps there to try and factory reset, mainly by using the factory reset GUI: https://dev.ti.com/gallery/view/TIMSPGC/MSPM0_Factory_Reset_Tool 

    Thank you so much for the Segger read out, but could you please also give me some more information on how you got the device in this state?  Were you debugging a code example?  Do you know if you were knowingly erasing/programming the NonMain memory?   

    Thanks,

    JD

  • 0 in reply to JD Crutchfield
    Prodigy 90 points

    Hi JD

    thanx for the GUI link. I'll try to reset the device.

    I'm not really shore how I managed to put device in this state. I wasn't doing simple flasher operations just to get familiar with the flasher itself: connect/disconnect, ram write test, flash write/read. I haven't intentionally written to NonMain section, I had this disabled in flasher settings. 

    I analyzed last  flasher log and what I could find is that after successful Connect command voltage dropped to 0V. When Disconnect command was invoked it hasn't even started (OnDisconnectTarget()), it just wrote Disconnected. After this new connection wasn't possible anymore.

    I will try to recrate the issue and give you a feedback.

    lp, Goran

  • 0 in reply to Goran Demšar
    TI__Mastermind 29075 points

    Hey Goran,

    Thank you for the additional information.  Please let me know if the factory reset works for you and then, if you can recreate it.

    Thanks,

    JD

  • 0 in reply to JD Crutchfield
    Prodigy 20 points

    Hi JD,

    I used factory reset tool and managed to bring some samples (not all of them to life). I still can't say what caused them to be non responsive. 

    I noticed additional strange thing. I would like to use only 2 pins (CLK and DIO), without the reset to program MSPM0C1104. According to documentation this could possible. If I try to flash evaluation board (LP-MSPM0C1104) with the same program, flashing is successful with or without Reset connected. 

    Without reset connected I get this in CSS-Theia: 

    JTAG Communication Error: (Error -1001 @ 0x0) Requested operation is not supported on this device. (Emulation package 12.7.0.00062)
    CS_DAP_0: Error connecting to the target: DAP Connection Error. This could be caused by the device having gone to low power mode. Try forcing an external reset.If the error persists, try forcing BSL, a Mass erase or a Factory Reset. Check device FAQs for more information.

    I am not putting MCU in a low power mode intentionally. Even with only a while(1); loop in main the result is the same. Could it be possible that the Factory reset is not done properly??

    Regards,Goran

  • +1 in reply to Goran_2 Demsar
    Guru 42085 points

    Sometimes I have to reset mine twice. I have *never* had this issue until I started setting aside sections of flash for some non-volatile storage.

  • 0 in reply to Goran_2 Demsar
    TI__Mastermind 29075 points

    Hey Goran,

    Is your application possibly disabling the reset or debug pins?  

    While it is possible to program the device with only two pins, the programmers might use some functions/commands that require, or at least assume, that it  has control of the Reset pin.  The only one that comes to mind specifically is the Factory Reset command it's self.  There is an Auto and manual DSSM commands, but the way these commands work is the Factory reset command is written to the DSSM inbox in the debug sub system and then the device needs to be reset to actually act on that command.  Auto has the programmer toggle the reset line while manual will prompt the user to do it. 

    Either way, if you can now program and debug the devices then the factory reset seems to have worked. 

    I'm still investigating the initial CCS error.  My working theory is that it has something to do with the NONMAIN memory as it's the only thing that should be able to restrict access to the device.  

    Just to reconfirm: when the device first showed this error, were you using a stand-alone XDS110 or the one built on the launchpad? 

    Also very interesting that you have multiple samples you say are showing this.  How many locked and how many could you recover?  Did you program them back to back?  Would it be possible to share the code or the .out that first caused the problem?  

    Thanks

    JD