MSP430FR59xx JTAG fuse resetting problem

Stephen Cool

Other Parts Discussed in Thread: MSP-FET

I am trying to secure my device by blowing the JTAG fuse on a MSP430FR59xx.

I am doing this by writing 0xAAAA to JTAG signature 1 (originally 0x0000) and 0x0004 to JTAG signature 2. The device is JTAG password protected and the JTAG signatures are stored in a static struct @ 0xFF80. I can see this correctly happening when the device is powered on. However, when the device is turned off then on, JTAG signature 1 resorts back to 0x0000.

Summary:

1. 0xAAAA to jtag sig1 @ 0xFF80 and 0x0004 to jtag sig2 @ 0xFF84

2. Device power down then power up

3. JTAG sig1 - 0x0000 (the original value)

***How do I preserve the JTAG signatures across device resets? How are they being overwritten?

Stephen

over 9 years ago

0 Stephen Cool over 9 years ago

Prodigy 70 points

I have tried #pragma RETAIN without success

0 Jim Patten over 9 years ago in reply to Stephen Cool

Expert 1060 points

Hi Stephen,

Did you ever get resolution to this post?

I'm using the FR5969 and trying to lock the JTAG. Looking at the spec, one needs to set 0xAAAA at address 0xFF80 (JTAG Signature 1) and anything else (other than 0x5555) at address 0xFF82 (JTAG Signature 2).

I had a similar problem when doing the following:
__no_init uint16_t jtag_signature1 @ 0xFF80;
__no_init uint16_t jtag_signature2 @ 0xFF82;

code snippet:
...
...
jtag_signature1 = 0xAAAA;
jtag_signature2 = 0x0000;

This would not lock the the data at the address after a power down/up.

So I modified the Linker file lnk430fr5969.xcl in my project
// ---------------------------------------------------------
// JTAG signature
-Z(CONST)JTAG_SIGNATURE_1=FF80-FF81
-Z(CONST)JTAG_SIGNATURE_2=FF82-FF83

and in the code:
const uint16_t jtag_signature1 @ "JTAG_SIGNATURE_1" = 0xAAAA;
const uint16_t jtag_signature2 @ "JTAG_SIGNATURE_2" = 0x0000;
#pragma required=jtag_signature1
#pragma required=jtag_signature2

This seems to work. On power up the addresses are stored in FRAM

HOWEVER, it does NOT lock the JTAG and someone could get the User Code.

So my question to the audience, what is going on?

Per the TI users guide SLAU367D page 57:
1.13.2 JTAG and SBW Lock With Password
A device can also be locked by writing 0AAAAh to JTAG Signature 1 and writing JTAG Signature 2 with
any value except 05555h.

Thanks,
-Jim

0 Jim Patten over 9 years ago in reply to Jim Patten

Expert 1060 points

It appears one needs to write 0x5555 to both addresses per the spec:
1.13.1 JTAG and SBW Lock Without Password
A device can be locked by writing 05555h to both JTAG Signature 1 and JTAG Signature 2. In this case,
the JTAG and SBW interfaces grant access to a limited JTAG command set that restricts accessibility into
the device. The only way to unlock the device in this case is to use the BSL to overwrite the JTAG
signatures with anything other than 05555h or 0AAAAh.

So I changed the above to:
const uint16_t jtag_signature1 @ "JTAG_SIGNATURE_1" = 0x5555;
const uint16_t jtag_signature2 @ "JTAG_SIGNATURE_2" = 0x5555;

And now the JTAG is seized up - LOCKED.

-Jim

0 Katie Pier over 9 years ago in reply to Jim Patten

TI__Guru 68116 points

Jim Patten said:
Per the TI users guide SLAU367D page 57:
1.13.2 JTAG and SBW Lock With Password
A device can also be locked by writing 0AAAAh to JTAG Signature 1 and writing JTAG Signature 2 with
any value except 05555h.

Jim,

That part you quoted is for doing lock with password. However it looks like your code sets a password length of 0 - so you are still able to get into the part. If you go one or two more lines further down the paragraph here:

A device can also be locked by writing 0AAAAh to JTAG Signature 1 and writing JTAG Signature 2 with any value except 05555h. In this case, JTAG and SBW interfaces grant access to a limited JTAG command set that restricts accessibility into the device as in Section 1.13.1, but an additional mechanism is available that can unlock the device with a user-defined password. In this case, JTAG Signature 2 represents a user-defined length in words of the user defined password. For example, a password length of four words would require writing 0004h to JTAG Signature 2. The starting location of the password is fixed at location 0FF88h. As an example, for a password of length 4, the password memory locations would reside at 0FF88h, 0FF8Ah, 0FF8Ch, and 0FF8Eh.

Right now, by setting 0000h for JTAG Signature 2, you set the password length to 0.

A couple options for you:

1. Lock without password

- if you don't need to ever get back in with JTAG (only BSL access), just set the lock without password per www.ti.com/lit/pdf/slau367 section 1.13.1. In this case, instead of setting AAAAh for the first signature and anything besides 5555h for the second signature, you will instead set both signatures to 5555h.

2. If you still want lock with password, you can set the password by setting the second signature to some number (e.g. 2 words, or 4 words, etc). Then starting at FF88h set a password.

Additional notes:

In production, if you just want to lock without password most programmers (MSP-FET, Elprotronic FET-Pro430 software) usually have a "blow fuse" option that will just do this for you. Or you could still include it in your code image this way.

Regards,

Katie

EDIT: I see now while I was typing you were able to get the "without password" method working - glad to hear it. Hopefully this provides more info on why the first method didn't work for you and info for others in the future.

0 Jim Patten over 9 years ago in reply to Katie Pier

Expert 1060 points

Thanks Katie! Got it.

But now that opens up the next question regarding the document just below in the NOTE section.

NOTE: Entering the password via the tool chain is done using 32-bit mode (two words).
The least significant word is entered first for each two-word transfer. For example, if the password
location contains: @0xFF8C = 0x45670123CDEF89AB4321, the password
must be entered as 0x0123456789ABCDEF4321 via the tool chain.

Regarding this note, since the password location starts at 0FF88h, why does this
NOTE show ("contains") @0xFF8C = 0x45670123CDEF89AB4321?

Does this mean that FRAM memory location 0xFF88==0x45, 0xFF89==0x67, 0xFF8A==0x01, etc?
This example is very confusing.

Plus, how long can this JTAG Signature2 password be?

Thanks,
-Jim

0 Katie Pier over 9 years ago in reply to Jim Patten

TI__Guru 68116 points

Hi Jim,

It sounds like the same thing was reported recently in this other post and we're already working to update the documentation/tools support. http://e2e.ti.com/support/microcontrollers/msp430/f/166/p/393933/1392922#1392922

Jim Patten said:
Plus, how long can this JTAG Signature2 password be?

So the JTAG signature 2 theoretically could be any value, but practically, I think you are limited because you will start running into the interrupt vectors of the part. You can use these interrupt vectors as part of your password if you want, it just means you aren't going to have a user-defined value there but rather the value will be whatever is the address of the corresponding ISR. Because that can start to get complicated, sometimes people don't want to include these and so keep their password short enough that they don't hit the interrupt vectors. You can find the addresses where you'll start having interrupt vectors, by looking in your device datasheet at the table "Interrupts Sources, Flags, and Vectors".

Regards,

Katie

0 Katie Pier over 8 years ago in reply to Katie Pier

TI__Guru 68116 points

I wanted to share for anyone finding this thread in the future - we just released an app note with code and detailed examples of enabling JTAG lock with password using CCS and IAR, as well as covering the differences JTAG locking features between MSP families. www.ti.com/.../slaa685 www.ti.com/.../slaa685

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

MSP430FR59xx JTAG fuse resetting problem