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: ERASE_USER_CODE when device is locked out and RESET configured as NMI

Part Number:

Normally, when locking the CPU by writing stuff to JTAGSIGNATURE and
BSLSIGNATURE, you can still get it back by issuing an ERASE_USER_CODE
command (including losing your flash contents of course).

However, this seems to fail when the RESET pin had been configured in
NMI mode. I have used these commands during initialisation of my code

bis     #SYSNMIIES, &SFRRPCR
bis     #SYSNMI, &SFRRPCR
bis     #NMIIE, &SFRIE1

and locked the two *SIGNATURE sections and used MSPFlasher -e ERASE_USER_CODE
using an MSP-FET and the SBW-Interface and it just told me that the
debug interface had been locked (it works when NOT enabling the NMI
feature). Luckily I got the device back by using the monitor programme
in my software to overwrite SFRRPCR contents.

Is this the expected behaviour and is it documented somewhere (I didn't
find anything)? If not it might qualify for an errata note if there is no other
way to get the CPU back...

  • If the JTAG/SBW signature from FF80h-FF83h has been written with any value other than FFFF_FFFFh or 0000_0000h then the JTAG/SBW should be locked and the device inaccessible through the MSP430-FLASHER software tool, regardless of the RST/NMI/SBWTDIO pin settings (Table 1-5 of the Family User's Guide SLAU445). If the BSL signature similarly disables the BSL (5555_5555h at FF84h-FF87h) then you should be entirely unable to communicate with the device. RST or NMI functionality determines whether BSL or 4-wire JTAG is enabled after the entry sequence is executed (Figure 1-12 of the JTAG User's Guide SLAU320). BSL is not started by the BSL RESET vector if configured for NMI functionality (Section 3.3.2 of the FRAM BSL User's Guide SLAU550).

    Regards,
    Ryan
  • Ryan Brown1 said:
    If the JTAG/SBW signature from FF80h-FF83h has been written with any value other than FFFF_FFFFh or 0000_0000h then the JTAG/SBW should be locked and the device inaccessible through the MSP430-FLASHER software tool, regardless of the RST/NMI/SBWTDIO pin settings...

    JTAG fuse value / signature (on 0FF80h) is irrelevant for mailbox system, that is used (in combination with boot code) to unlock device (back to factory state) by ERASE_USER_CODE, and MSP430-FLASHER can do it on locked device. You was writing the same, one year ago.

    https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/566104/2074674#2074674 

  • Hey zrno,

    Thanks for once again catching my mistake and correcting it. I will have to resolve to learn more about the MSP430-FLASHER and JMB System for the new year.

    Regards,
    Ryan
  • Andre Albsmeier said:

    Part Number: MSP430FR4133

    Normally, when locking the CPU by writing stuff to JTAGSIGNATURE and
    BSLSIGNATURE, you can still get it back by issuing an ERASE_USER_CODE
    command (including losing your flash contents of course).

    However, this seems to fail when the RESET pin had been configured in
    NMI mode. I have used these commands during initialisation of my code

    bis     #SYSNMIIES, &SFRRPCR
    bis     #SYSNMI, &SFRRPCR
    bis     #NMIIE, &SFRIE1
    

    and locked the two *SIGNATURE sections and used MSPFlasher -e ERASE_USER_CODE
    using an MSP-FET and the SBW-Interface and it just told me that the
    debug interface had been locked (it works when NOT enabling the NMI
    feature). Luckily I got the device back by using the monitor programme
    in my software to overwrite SFRRPCR contents.

    Is this the expected behaviour and is it documented somewhere (I didn't
    find anything)? If not it might qualify for an errata note if there is no other
    way to get the CPU back...

    From slau320...

    MSP430 devices with Spy-Bi-Wire (SBW) access

    The SBW interface and any access to the JTAG interface is disabled while the TEST/SBWTCK pin is
    held low. This is accomplished by an internal pulldown resistor. The pin can also be tied low externally.
    Pulling the TEST/SBWTCK pin high enables the SBW interface and disables the RST/NMI functionality
    of the RST/NMI/SBWTDIO pin. While the SBW interface is active, the internal reset signal is held high,
    and the internal NMI signal is held at the input value seen at RST/NMI with TEST/SBWTCK going high.

    If NMI (still) disable SBW entry sequence than I will power-up target device, with RESET pin low (from FET). There are more than one type of SBW entry sequence, also starting with RESET pin low. I guess that this should give full control to FET over target device, before executing / running any instructions (and enabling NMI state) on target device.

  • > If NMI (still) disable SBW entry sequence than I will power-up target device, with RESET pin low (from FET). There are more than one type of
    > SBW entry sequence, also starting with RESET pin low. I guess that this should give full control to FET over target device, before executing /
    > running any instructions (and enabling NMI state) on target device.

    This might work. However, this would require
    1. The ability to control MSP-FET's behaviour regarding RESET before it starts to run the entry sequence
    2. Some interaction with the user to tell him when to power on the device
    Both things I didn't find (at least with MSPFlasher)
  • > I will have to resolve to learn more about the MSP430-FLASHER and JMB System for the new year.

    After learning, please advise how to ERASE_USER_CODE a locked FR4133 with the RESET pin configured to NMI :-)
  • Andre Albsmeier said:

    This might work. However, this would require
    1. The ability to control MSP-FET's behaviour regarding RESET before it starts to run the entry sequence
    2. Some interaction with the user to tell him when to power on the device
    Both things I didn't find (at least with MSPFlasher)

    MSP-FET / eZ-FET Lite hardware / firmware / DLL and MSP-Flasher are open source.

    http://www.ti.com/tool/MSPDS

    (I don't have time, but if you want) you can search and find on this forum, posts of successfully customized FET's.

  • MSP-Flasher can't do this, no need to search further.

    Initially, I just wanted to know if the observed behaviour is as expected and/or documented
    and if there is a (documented) solution around it. From TI came nothing (usable) -- while your
    idea might work if someone digs into the internals of MSPDS and whatever.

    So people can see this post as a heads-up if they intend to use the NMI function and securing
    the debug interface(s) that they later might run into problems to get the device back.

**Attention** This is a public forum