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.

MSP430FR5957: Mass erase including IPE data using UART BSL

Part Number: MSP430FR5957

Tool/software:

We have our device protected with IPE. We would like to be able to reset the device to factory settings and reprogram it with new code. It looks like IPE configration data is stored only the first time it is enabled in the device. Standard mass erase does not erase that memory section.

(SLAU367P) 9.6.1.1.1 Trapdoor Mechanism for IP Structure Pointer Transfer:

The bootcode performs a sequence to ensure the integrity of the IPE structure pointer. On bootcode execution, a valid IPE Signature 1 triggers the transfer of the IPE Signature 2 (IPE structure pointer source) to a secured nonvolatile system data area (saved IPE structure pointer). This transfer only happens once if no previous secured IPE structure pointer exist. Subsequent of a successful transfer of the IPE structure pointer, the IPE Signatures can be overwritten by any value without compromising the existing IP Encapsulation

(SLAU367P) 9.6.2 IP Encapsulation Removal:

After successful instantiation of an IP protected memory area, a mass erase erases only the memory area outside of the IP Encapsulation. To perform an erase of all memory locations in main memory and to remove the IPE structure pointer, a special erase sequence must be performed. For more details, see the MSP430 Programming With the JTAG Interface. For details on how to initiate this erasure from the IDE, see the Code Composer Studio for MSP430 User's Guide

The only option to restore the device to factory defaults showed in the documentation requires JTAG interface to be used. Is there any alternative way to do this via UART BSL?

  • Hello,

    Reading the documentation, I don't see any way to reset the IPE via BSL.  It looks like a full device wipe is only possible via the JTAG interface, as you concluded.  

    Thanks,

    JD

  • Thanks for your prompt response JD. The conclusion is not what I was expecting, but life is cruel some times.

    There is yet some piece of information which I do not completely understand.  There is a Note in 

    (SLAU367P) 9.6.2 IP Encapsulation Removal:

    NOTE: An invalid IP Encapsulation init structure or a saved IPE structure pointer with an invalid target (not pointing to a valid IP Encapsulation init structure) causes an erase of all nonvolatile memory segments including the IP Encapsulation segments and the init structure during bootcode execution. This setup error leads to a completely unprogrammed device after the next bootcode execution. This mechanism ensures that no exposure of IP code can happen by a misconfiguration or a memory corruption.

    Case 1 - An invalid IP Encapsulation init structure:

    Does this check occur always? Or only the first time IPE is initialized?

    Case 2 - A saved IPE structure pointer with an invalid target:

    if we overwrite the content of the structure within the IPE section (from our code executing from IPE section) to an invalid configuration, and reboot the device, will the erase happen?

    Case 3 - Is there a way to trigger this action from the program itself running the code outside IPE section? Even if not directly via BSL we could use BSL to load a different program to the device not using the IPE area and execute some code to trigger this erase action.

    It is annoying that only JTAG access can be used to reset an IPE protected device. 

  • Hey Ibon,

    I was thinking about this method as well, but I didn't see a clean way to do it.   

    Case 1: I think this happens every boot.  My understanding is that the IP structure pointer is locked in only once, but at each power up, the boot code jumps to that pointer looking for the IP structure.  So I do think an "invalid" IP structure would cause a mass erase.   I guess an "invalid" IP structure means the MPUCHECK parity doesn't match.  

    Case 2: Actually, I do think this could work.  

    Case 3 - Based on the above, looks like no. 

    Hope this helps,

    JD 

**Attention** This is a public forum