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.

MSP430FR4133: MSP-FET "ERROR: Could not reset device" during password protected device programming

Part Number: MSP430FR4133
Other Parts Discussed in Thread: MSP430-FLASHER, UNIFLASH, MSP-FET

Same as in https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/791143/msp430fr5964-msp-fet-error-could-not-reset-device-during-password-protected-device-programming applies when programming an MSP430FR4133 and the code has the JTAG locked out.:

...
* Setting VCC to 3300 mV...done
* Accessing device...done
* Reading device information...done
* Loading file into device...
# Exit: 10
# ERROR: Could not reset device
* Resetting device (RST/NMI)...done
* Starting target code execution...done
* Disconnecting from device...done
...

I am using msp debug stack 3.15.0.1 which is not the newest but according to the revisions.txt, nothing

has changed w.r.t. this in the current version.

  • Hi Tom,

    Does this issue only happen using the MSP430-FLASHER or does it also happen when you use Uniflash?

    Note: Uniflash does have a command line interface option if that is a requirement.

    Regards,

    Luke

  • Hi,

    well, I tried uniflash a while ago and now again. It doesn't work at all -- it offers three "TI MSP430 USBx"
    connections (I only have one MSP-FET connected) and gives me "Cannot read property 'DS' of undefined"
    regardless of which one I select...

    But this is about MSPFlasher and I found out some more info:

    I tried the same as I did on Windows (before it was linux) and encountered the same issue (Exit: 10, Error...)
    This was when using MSPFlasher 1.3.20 and the accompanying DLL 3.14.0.0 (on linux it was MSPFlasher 1.3.20
    and debug stack 3.15.0.1)

    When using MSPFlasher 1.3.15 (and DLL 3.10.1.000) it does not happen. So I swapped the DLLs and the results are:

    MSPFlasher 1.3.20 and DLL 3.10.1.000 shows the error.
    MSPFlasher 1.3.15 and DLL 3.14.0.0 does NOT show the error.

    So the problem lies in MSPFlasher itself (which makes more experiments using uniflash probably useless).

    The bug was introduced with this change when going form MSP Flasher v1.3.17 to MSP Flasher v1.3.18:

    diff -ru 17/Source/MSP430_Flasher.cpp 18/Source/MSP430_Flasher.cpp
    --- 17/Source/MSP430_Flasher.cpp        2021-12-04 11:45:51.000000000 +0100
    +++ 18/Source/MSP430_Flasher.cpp        2021-12-04 11:46:46.000000000 +0100
    @@ -43,7 +43,7 @@
     *
     * \author Bob Heilmaier
     *
    -* \version 1.3.16.0
    +* \version 1.3.18.0
     *
     * \file MSP430_Flasher.cpp
     *
    @@ -172,7 +172,7 @@
     
     //==RESET DEVICE=============================================================//
     
    -        StdUseCase_Reset(PUC_RESET, 0, 0);
    +        StdUseCase_Reset(FORCE_RST_RESET, 0, 0);
     
     //==SET BREAKPOINTS==========================================================//
     
    

    The only thing the README has to say is:

     Change Log:
     ===========
    +v1.3.18 May 15, 2018
    +---------------------
    +- Updated Flasher packages with MSP Debug Stack v3.13.0
    +- Validated Software Manifest
    +
    +v1.3.17 February 26, 2018
    

    which has nothing to do with this change.

    After reverting this back in v1.3.20, everything is OK again.

  • Thanks for testing different configurations and getting back to us with the findings. Are you able to flash the device with your current MSP-FLASHER version and DLL?

    Regards,

    Luke

  • I was able to flash it all the time. However, the error confused me so
    I started digging around and ended here after finding out that other
    people saw the same effects.
     
    As I wrote, I can even use the current MSPFlasher 1.3.20 without emitting
    mentioned Error after reverting the undocumented change between MSP
    Flasher v1.3.17 and MSP Flasher v1.3.18.
     
    I suggest getting in touch with the folks who changed PUC_RESET to
    FORCE_RST_RESET and revert it back. If FORCE_RST_RESET is needed for whatever
    reasons, it could be made a command line switch for people who blow the
    JTAG password during code programming (like I do on my FR4133).

**Attention** This is a public forum