• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 79 subscribers
  • Views 212 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430FR5994: Lock JTag with Hex430 possible?

Mike52327
Intellectual 450 points
Part Number: MSP430FR5994
Other Parts Discussed in Thread: UNIFLASH

Hello,

For our project, I want to lock the JTag and I already have such working by setting the fill value in the linker for the JTag password to 0x5555 as below.

JTAGSIGNATURE           : origin = 0xFF80, length = 0x0004, fill = 0x5555 /* Lock Jtag no password, BSL to override */

This works fine, and allows me to debug on the next load.  However, and obviously, any subsequent load states that the JTag is secured.  We have our own PC tool that uses the BSL and I am able to unsecure the JTag, but am looking for a more development friendly solution...  In the current setup, after every debug session I have to use a separate tool to unlock the JTag... (requires disconnecting the emulator, since our programming board needs to control the TEST and RST lines to get into bootloader mode)

So, is there a way to do either of the below?

  1. Configure CCS to do a mass erase (we have masserase still enabled) prior to any debugging?  The mass erase would have to be done thru the JTag emulator...
  2. Is there a way to use the HEX430.exe tool to flip the JTag signature when creating our output binary?  I see we can fill holes, but seems it fills all or none with specified value.  I would only want to specify the JTag signature to get updated.  Then we can leave the linker command file with the jtag signature as open, and the HEX tool could "lock" the Jtag for us...
    For this, I was trying to modify our ROMS section in our HEX430 config to separate out the JTAGSIGNATURE section and just fill, but I get memory ranges out of order errors...  Also I am only providing one file name where I believe each ROMS clause needs a file name...
  3. other options welcome...

I realize I can probably write a simple python script to post process what our use of HEX430 outputs and flip the 4 bytes, but looking to minimize the number of custom scripts our build is dependent on.

Thanks,

-mike

  • 0
    TI__Mastermind 49692 points

    Hi Mike,

    Thanks for your post. From my understanding, the JTAG lock is to secure the device's JTAG interface to prevent unauthorized access after production. Thus, enabling the JTAG lock would most likely be enabled in your production code. However, during development, I would not recommend trying to enable the JTAG lock. You know that it works now and can come back later to add it to your production code. Perhaps I've misunderstood the context of your question though.

    HEX430 seems to be an outdated, heavily manual tool. For simply erasing the part, CCS (or even UniFlash) can be used for that. In CCS, you can change your CCS project properties to erase certain sections of memory on the device before programming it.

    CCS project > Properties > Debug > MSP430 Flash Settings > Erase Options

  • 0
    Guru 33653 points

    Hi Mike,

    MSP430FR2xx and MSP430FR4xx can be mass erased (back to factory state) using mailbox system by existing SBW / JTAG connection even with secured JTAG. MSP430FR5xx also can be mass erased (back to factory state) using mailbox system by existing SBW / JTAG connection, but unfortunately only with unsecured JTAG. This option (mass erase my mailbox system) is covered by CCS, as you can see here...

**Attention** This is a public forum