MSP430 FR5969 launchpad evaluation kit

irene donati said:

P.s. in my code , my intent isn't to blow the security code, the only things i'm doing is to write some datas in memory.

ok, it just turned out that i've been accidentally  writing some datas in between  0xff80 and 0xFFFF FRAM memory which is supposed to be the memory portion reserved for interrupts and signatures.

How can i recover from this mess?

hi,

are you sure you are writing exactly 0x5555 (or 0xAAAA) to JTAG Sgnature 1 and Signature 2? Referring to User's Guide, JTAG can be only locked when writing _exactly_ this value (see SLAU367B chapter 1.13.1 and 1.13.2).

If it is true, you can try to check whether the BSL is still accessible, because unless you are writing the exact word 0x5555 to the BSL Signature 1 (address 0xFF84) and Signature 2 (address 0xFF86), the BSL should be still accessible. With the BSL, you can try to alter the the value of the JTAG lock.

If both don't work, just desolder the device from the kit, and get a new one :)

It is a rather common mistake. The FR devices have a software ‘fuse’ for JTAG. On power-on, JTAG is disabled. The internal boot code will check a certain memory address for being 0xFFFF. If not, then JTAG will stay disabled. This ‘JTAG Key’ is located at the bottom of the interrupt table, where there are unused interrupt vectors. The latest CCS version has excluded this area from both, main code flash and vector table segment, so it can’t be accidentally used anymore. However, this change has cause existing projects to be incompatible (as they still contain the old linker scripts) with the new header files. As a result, not only old projects won’t run anymore without a manual change, but worse, they may blow this JTAG fuse too, due to the (now) disarrangement of the interrupt vectors.
It of course doesn’t protect the fuse from being blown by the application itself.

The users guide tells that only writing 0x5555 or 0xaaaa will cause the lock (as Leo cited), but this wouldn’t explain the (compared to this very unlikely case) large number of accidental lock-ups. It may have its reason in experimental silicon or older silicon revisions where the fuse wasn’t working as intended. Honestly, I don’t know.

 However, there’s a way to recover:

Almost all MSPs contain a factory-programmed bootstrap loader (BSL). It allows erasing the MSP content (this will also reset the JTAG fuse, in case of the FR devices) and uploading a new firmware.
Connection is done by attaching a serial (TTL level) interface to RST, TEST (DTR+RTS signal?) and two timer pins (for RX and TX). See the device datasheet for the exact connections. Then you can use BSL scripter to perform a mass erase and/or upload a new firmware.

See here http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=slau319&fileType=zip
And there http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=slau319&fileType=pdf

Hi, thanks you all for the prompt answers

I got that there is a sequence to do to operate the mass erase by BSL by using an appropriate board as suggested in : http://www.ti.com/lit/ug/slau319h/slau319h.pdf

But i don't understand how to pratically do it by using the evaluation board that i am using

otherwise i think i will go for the replace micro solution

Thanks again

irene

Rather clear that the depth, focus & crystal-clear direction w/in, "Jens-Michael's" response demands bit beyond poster's surprisingly indirect, "group thanks."  [imho & many w/in our design team!]

Bravo Jens-Michael - once again you rise far, "above & beyond!"   Thank you - know that your efforts are very much appreciated.  (even by those who prefer ARM {especially MSP competing, "cost-free" M0} exiled this vendor's terrain...)

Leo Hendrawan said:

are you sure you are writing exactly 0x5555 (or 0xAAAA) to JTAG Sgnature 1 and Signature 2? Referring to User's Guide, JTAG can be only locked when writing _exactly_ this value (see SLAU367B chapter 1.13.1 and 1.13.2).

Jens-Michael Gross said:

The users guide tells that only writing 0x5555 or 0xaaaa will cause the lock (as Leo cited), but this wouldn’t explain the (compared to this very unlikely case) large number of accidental lock-ups. It may have its reason in experimental silicon or older silicon revisions where the fuse wasn’t working as intended. Honestly, I don’t know.

As I already noted on another topic (http://e2e.ti.com/support/microcontrollers/msp430/f/166/p/334720/1169649.aspx#1169649), only 5555h 5555h will lock JTAG (secured mode), but any other value (protected mode) will enable JTAG if device is unlocked (using JTAG, not BSL) with right password. However, don't know how this (handling JTAG password on FRAM devices) is supported by TI software /  FET's.

From slau320 MSP430™ Programming Via the JTAG Interface ...

FRAM-based devices use a LockKey that is written into a special location to secure the device. The
devices support two different levels of protection: "protected mode" and "secured mode".
In the protected mode, the application can define a password and protect the device with this password.
The UnlockDevice function could be used to connect to the device by applying the correct password (see
Section 1.4.4 for detailed information). For general information about the password, see the
MSP430FR57xx Family User's Guide (SLAU272).
In the secured mode, the device cannot be accessed through JTAG. To enable the secured mode, write
0x55555555 to the memory location 0xFF80. After writing the password, a BOR is required to enable the
security fuse.

//----------------------------------------------------------------------------
//! \brief This function unlocks the Fram memory when a JTAG password is set.
//! \param[in] unsigned short* password (Pointer to array containing the JTAG
//! Password)
//! \param[in] unsigned long passwordLength (length of the password in words)
//! \return word (STATUS_OK if memory unlock was successful, STATUS_ERROR
//! otherwise)
word UnlockDeviceXv2(unsigned short* password, unsigned long passwordLength)
{    
  /*----------------------------------------------------------------------- */
  /*            phase 1 of device entry using a user password               */
  /*------------------------------------------------------------------------*/
 
    // Enable the JTAG interface to the device.
    ConnectJTAG();     
    // Apply again 4wire/SBW entry Sequence.
    // set ResetPin =0
#ifdef SPYBIWIRE_MODE
    StartJtag(RSTLOW_SBW);
#else           
    StartJtag(RSTLOW_JTAG);
#endif        
    // reset TAP state machine -> Run-Test/Idle
    ResetTAP();
    // shift in JTAG mailbox exchange request
    if(((word)IR_Shift(IR_JMB_EXCHANGE)) == JTAG_ID91)
    {   
        // check if JTAG mailbox is ready & perform input request
        if((DR_Shift16(0x0011) & 0xFFF0) == 0x1200)
        {
            // shift in A55A to set device into lpm 4
            DR_Shift16(0xA55A);       
            // and feed in perform password exchange request
            DR_Shift16(0x1E1E);          
        }
        else
        {
            return(STATUS_ERROR);
        }
    }
    else
    {
        return(STATUS_ERROR);    
    }
    StopJtag();
    /*----------------------------------------------------------------------- */
    /*            phase 2 of device entry using a user password               */
    /*------------------------------------------------------------------------*/
    // Enable the JTAG interface to the device.
    ConnectJTAG();  
    // Apply again 4wire/SBW entry Sequence.
#ifdef SPYBIWIRE_MODE
    StartJtag(RSTHIGH_SBW);
#else
    StartJtag(RSTHIGH_JTAG);
#endif          
    // reset TAP state machine -> Run-Test/Idle
    ResetTAP();
    // shift in JTAG mailbox exchange request      
    if( IR_Shift(IR_JMB_EXCHANGE) == JTAG_ID91)
    {
        unsigned short i = 0;
        unsigned short timeOut = 0;
        
        while(i < passwordLength)
        {
            MsDelay(10);
            // check if JTAG mailbox is ready & perform input request
            if((DR_Shift16(0x0001)) && (timeOut < 600))
            {
                // and feed in password beginning with the length
                DR_Shift16(password[i]);  
                MsDelay(1);
                i++;
                timeOut =0;
            }
            else // if JTAG mailbox is not ready try again until timeout is reached
            {
                timeOut++;
                if(timeOut == 600)
                {
                    return(STATUS_ERROR);  
                }
            }
        }    
    }
    else
    {
         return(STATUS_ERROR);
    }        
    return(STATUS_OK);
}

cb1_mobile: thanks, you make me blush. J How come you read this? Haven’t seen you around for quite a long time. You’ve been only around the Tivia and Stellaris forum for 8 months now.

 Zrno Soli: So this proves my analysis of the reported cases: 0x55555555 is a total lock, 0xffffffff is total freedom and anything else is password-protected, only that no tool supports the password. (haven’t seen support for the JTAG mailbox too, which is almost the same, as the password apparently is checked against the mailbox content after BOR) And even if, in most of these accidental cases, the ‘password’ is unknown anyway. This should be added to the errata list of these devices.

Jens-Michael Gross said:

 Zrno Soli: So this proves my analysis of the reported cases: 0x55555555 is a total lock, 0xffffffff is total freedom and anything else is password-protected, only that no tool supports the password. (haven’t seen support for the JTAG mailbox too, which is almost the same, as the password apparently is checked against the mailbox content after BOR) And even if, in most of these accidental cases, the ‘password’ is unknown anyway. This should be added to the errata list of these devices.

You’re right, it isn’t unknown. It is just difficult to retrieve. Even I cannot directly read and understand an ELF file, and in most cases, TI TXT generation is not enabled – and on a rebuild to get it, the outcome may be different.