CCS/MSP430FR5738: JTAG password usage in CCS & MSP Flasher

Hi Vishal,

I am reaching out to our team for more info.

Thanks,

Mitch

Additional info.

Having set the security in the device, I can't unlock it with the MSP Flasher either. I've tried reversing the bytes / words just in case i was missing something, or the architecture of the device was important. It's basically behaving the same as using the -f flag in MSP Flasher (which also works by the way). But this is not what I need.

This is a production issue, flagged as a security concern. I have about 2 weeks to solve this, or I'll need to remove the device from the design. Please help.

Cheers.

Hi Al,

So just to clarify - you are able to set the JTAG password? One thing I wanted to ask was if you were resetting the device after providing the JTAG password?

Your .txt file matches the same format as our example in our Code Protection Features documentation (section 2.3.1), so it looks like you are assigning a JTAG password.

To unlock the device, can you try the steps outlined in section 2.3.1 in the document linked below?

http://www.ti.com/lit/an/slaa685/slaa685.pdf

Thanks,

Mitch

Hi Mitch. Great to hear back! So, I can apply the password. It's definitely secured, since I can't access it again, which is the problematic part. 

Now, after securing it, I've completely disconnected it from the programmer for a few seconds (or a full day at this point)  to make sure it's fully reset. I assume this fulfills the BOR requirement. 

As per my original post, I have tried to unlock the device using both CCS, as specified in the guide (the .ccxml file), and also using MSP Flasher -p flag. I did not use the -l flag as I gather that's deprecated and stops it working. 

Can you confirm that this process is working for the MSP430FR5738. At least, I know then that I can proceed with the production of the physical boards, with the assurance that there is a software based solution to issue. I'm online now with the board in front of me. I can jump through any hoops you want to get to the bottom of this...

Cheers,

Al.

Hey Al,

Thanks for the info.

So after looking at the error code, one potential issue is that the JTAG fuse might have been blown. If this is the case, the only way to access the FRAM memory is now through the BSL. 

Do you have another working unit you can test with? It might be helpful to start from scratch and simply provide the JTAG password (as you were doing before), reset the device (via a power cycle or other method), and then provide the JTAG password in CCS with the method described in the document.

Thanks,

Mitch

I can certainly give it a go at pain of bricking another device. I did purposely blow the fuse on one device (-f option) to see if doing ERASE_ALL type options through MSPFlasher would put it back to factory (it did not. Brick no.1). 

Let me just go get one for the chopping block.

Cheer,

Al.

Right. I must have had a blown device like you suggest. When I tired it again with a completely fresh device, it works. The only things I did differently were use 1234578 as the password, which is obviously not obligatory; and use the uint8_t and uint16_t types instead of the unsigned short etc. also should make no difference, since they are just typedefs.

It works fine from CCS and MSPFlasher. Next step is to switch to a more sensible password and increase the length a bit. Here's hoping I'm on a roll...

So, in terms of closing this down: the only explanation is that I had a blown device. But I have no idea why, but makes me nervous going into mass production. If I flash 1000 devices with the password protected firmware, how many will not come back to life??? And moreover, why not? There is a possibility I mixed up a purposely fused device, but I genuinely don't think so. Although that's very different from don't know so. I reckon i'll have a bit more of a play around with the few prototypes I have left and see if I somehow fuse another one. If I do, we may have an issue. If not, it's on me... I must have mixed them up.