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.

MSP430FR2355: MSP430FR2355 MSP430FR2xxx Electronic Fuse Lock code samples.

Part Number: MSP430FR2355
Other Parts Discussed in Thread: MSP430F5340

Hello,

I am looking for code samples to lock/ unlock MSP430FR2355 from the firmware.

According to the user manual 

"Locking the device requires the programming of two signatures in FRAM.
JTAG Signature 1 (memory address 0FF80h) and JTAG Signature 2 (memory address 0FF82h) control the behavior of the device locking mechanism.
A device can be locked by writing any value other than 0000h or FFFFh to both JTAG Signature 1 and
JTAG Signature 2."

I suppose that putting 0000 or FFFF back into the signatures from the program would unlock the device.

Where can I see such code example in IAR?

  • Hello,

    I wasn't able to locate any example software for locking the JTAG on MSP432FR2xx, but there is an example for MSP430FR5xx/6xx available that would be a good starting point.  We have a MSP Code Protection Features App Note that covers the locking of JTAG on the different families and includes a download for FR5xx Software examples.  

    You are correct that clearing the JTAG signatures would unlock the device, but this can only be done via a password protected BSL or somehow in your application code.  It cannot be done via JTAG or SBW. 

    I think the app note will answer most of your questions.  Let me know if you have any more follow up questions.

    Thanks,

    JD

  • JD Crutchfield said:

    You are correct that clearing the JTAG signatures would unlock the device, but this can only be done via a password protected BSL or somehow in your application code.  It cannot be done via JTAG or SBW

    FR2xx an FR4xx devices with locked JTAG access, can go back to factory (unlocked) state, by using SBW / JTAG mailbox system (user code erase).

  • Hello,

    Thank you for your response but let me clarify.

    We used MSP430F5340 before. 

    That MCU could be locked/ unlocked with the following code from within our code

    Lock

    while( ( FCTL3 & WAIT ) == 0 ); // ensure no FLASH write is in progress

    SYSBSLC = 0; // enable and unlock BSL segment 3
    FCTL4=FWKEY; // unlock INFO
    FCTL3=FWKEY; // unlock FLASH and INFO A
    FCTL1=(FWKEY+WRT);
    ( *(uint8_t*)0x17fc ) = 0x55;

    while( ( FCTL3 & BUSY ) == BUSY );

    FCTL1=FWKEY;
    FCTL3=(FWKEY+LOCK);

    Unlock 

    ...

    ( *(uint8_t*)0x17fc ) = 0x00;

    ...

    On the other hand MSP430FR2355  has these signatures in the main memory so would be just sufficient just to do the following in the code?:

    Unlock:

    ( *(uint8_t*)FF80h) = 0x00;

    ( *(uint8_t*)FF81h) = 0x00;

    ( *(uint8_t*)FF82h) = 0x00;

    ( *(uint8_t*)FF83h) = 0x00;

    Lock

    ( *(uint8_t*)FF80h) = 0x55;

    ( *(uint8_t*)FF81h) = 0x55;

    ( *(uint8_t*)FF82h) = 0x55;

    ( *(uint8_t*)FF83h) = 0x55;

  • Yes, this should work.
  • Hey Zrno,

    Good point on using the mailbox for mass erase! This would unlock the JTAG.

    Ferentes,
    I agree with Zrno that your firmware should work.

    Thanks,
    JD
  • Hello JD,

    I am trying to implement signature altering but cannot get it working.

    Can you sample some code which accomplishes a similar task for FRAM?

    Thanks,

    ferentes

  • Hey Ferentes,

    I do not have a code example for writing these signatures in FRAM, but there are 2 FRAM_write examples that show how to be able to write to FRAM memory: dev.ti.com/.../

    You are probably having 2 possible issues.

    1. The signatures don't take effect until after a BOR. (But I think you would have notice this if you power cycled)

    2. More likely, You need to clear the FRAM protection bits. This is the FPWP bit for this signature section of memory. More information can be found in the MSP430FR2355 User's Guide.

    Thanks,
    JD
  • Hello JD,

    Thank you for the example.

    I tested the following code on the launchpad and tried to see memory changed at the address 0xff80 in the debugger.
    The memory did not change. However when I changed the base address to 0x1800 as per example, I could see changes.
    Is there another protection mechanism for the area 0xff80?

    #include <msp430.h>

    unsigned long *FRAM_write_ptr;

    #define FRAM_TEST_START 0xFF80

    void FRAMWrite55 (void)
    {
    SYSCFG0 = FRWPPW | PFWP;
    *FRAM_write_ptr = 0x55555555;
    SYSCFG0 = FRWPPW | DFWP | PFWP;
    }

    void FRAMWriteFF (void)
    {
    SYSCFG0 = FRWPPW | PFWP;
    *FRAM_write_ptr = 0xFFFFFFFF;
    SYSCFG0 = FRWPPW | DFWP | PFWP;
    }

    int main(void)
    {
    WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer

    P1OUT &= ~BIT0; // Clear P1.0 output latch for a defined power-on state
    P1DIR |= BIT0; // Set P1.0 to output directionOUT

    PM5CTL0 &= ~LOCKLPM5; // Disable the GPIO power-on default high-impedance mode
    // to activate previously configured port settings

    while(1)
    {
    FRAM_write_ptr = (unsigned long *)FRAM_TEST_START;
    FRAMWrite55();
    FRAMWriteFF();
    }
    }
  • Found it. It was a wrong protection bit.

    Thank you for your help.

    The correct code

    void FRAMWrite55 (void)
    {
    SYSCFG0 = FRWPPW | DFWP;
    *FRAM_write_ptr = 0x55555555;
    SYSCFG0 = FRWPPW | DFWP | PFWP;
    }

    void FRAMWriteFF (void)
    {
    SYSCFG0 = FRWPPW | DFWP;
    *FRAM_write_ptr = 0xFFFFFFFF;
    SYSCFG0 = FRWPPW | DFWP | PFWP;
    }

**Attention** This is a public forum