• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 79 subscribers
  • Views 588 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP430F5342: "Device secured" message after custom BSL download

svl123
Intellectual 690 points
Part Number: MSP430F5342


Hello,

I have recently tried to create a custom BSL for the MSP430F5342 device using the template found in the MSP430 Custom BSL Package.

I used the template for the MSP430F543xA device and changed the memory map to a) adapt it to my device and b) load the BSL code into the BSL section (according to the .map file in the template, the code is loaded into flash starting at 0x10000 instead of the BSL area starting at 0x1000.) When trying to load the sample BSL code into the BSL area, there is not enough space and so an overflow area is needed. To accommodate this, I made the following modifications to lnk_msp430f5342.cmd:

In the MEMORY section:

    /* Get rid of INFO MEM sections
    INFOA                   : origin = 0x1980, length = 0x0080
    INFOB                   : origin = 0x1900, length = 0x0080
    INFOC                   : origin = 0x1880, length = 0x0080
    INFOD                   : origin = 0x1800, length = 0x0080 //Use this area for BSL OverFlow
	*/
    // Added BSL & BSLOF (overflow) section -------------------------------
    BSL						: origin = 0x1042, length = 0x7AE
    BSLOF					: origin = 0x1880, length = 0x200
	// --------------------------------------------------------------------

in the SECTIONS section:

	//Place all output sections into newly defined memory sections
    .text       : {} >> BSL | BSLOF			// Code
    .text:_isr  : {} >> BSL | BSLOF			// ISR code space
    .cinit      : {} > BSL | BSLOF	        // Initialization tables
    .const      : {} >> BSL | BSLOF         // Constant data
    .cio        : {} > RAM                  // C I/O Buffer

    .pinit      : {} > BSL | BSLOF          // C++ Constructor tables
    .binit      : {} > BSL | BSLOF          // Boot-time Initialization tables
    .init_array : {} > BSL | BSLOF          // C++ Constructor tables
    .mspabi.exidx : {} > BSL | BSLOF        // C++ Constructor tables
    .mspabi.extab : {} > BSL | BSLOF        // C++ Constructor tables

#ifdef __TI_COMPILER_VERSION__
  #if __TI_COMPILER_VERSION__ >= 15009000
    .TI.ramfunc : {} load=BSL | BSLOF, run=RAM, table(BINIT)
  #endif
#endif

The project compiled successfully and I was able to load it into the device. However, after loading it a few more times I am no longer able to access the device and get the message that

"Error connecting to the target:
The Debug Interface to the device has been secured"

I do not understand why this happened. I checked the BSL430_API.c file and the lock key is still 0xFFFFFFFF in my project so the JTAG fuse should not have blown. What is causing this behavior? Is it possible to unlock the device?

Thank you,

svl123

  • 0
    TI__Guru 56685 points
    Hello SVL,

    What value is located in memory addresses 0x17FC - 0x17FF? This is where the JTAG Lock key is supposed to be stored, and the device will be looking here for that key. I do not recommend moving the JTAG LOCK Key location as it complicates device access. Moving where the JTAG LOCK is located is not something we can readily support.

    You could still do the procedure to unlock the JTAG via BSL by clearing out the correct memory addresses. This could possibly give you back access, but there is a possibility of bricking your device as well due to if the JTAG Lock Key is moved and other BSL code resides in the same space. As you will be overwriting BSL code while executing BSL Code. To be sure, you could do a BSL in RAM, then then clear the appropriate memory section.

    Please see section "1.11.2 JTAG Lock Mechanism Using the Electronic Fuse" in the MSP430F5342 User Guide for more information about the JTAG Lock Mechanism.
  • 0 in reply to Jace H
    Intellectual 690 points

    Jace,

    Per your advice in my previous thread regarding the memory mapping I did not touch the JTAGLOCK_KEY area in MEMORY. It is still set to:

    JTAGLOCK_KEY            : origin = 0x17FC, length = 0x0004

    I do not know what value is stored at 0x17FC - 0x17FF because I no longer have access to the device. However, as I mentioned, the BSL430_API file has the line:

    const unsigned char JTAGLOCKKEY[JTAGLOCKKEY_SIZE] = {0xFF,0xFF,0xFF,0xFF};

    which would lead me to believe that the key has not changed? This is the same value that was here before when I repeatedly loaded BSL code into the device and I didn't change it.

    I don't think this device is recoverable because the intended application permits only software access to the BSL via jumping to 0x1000. What I want to know is, why this happened and how I can prevent it in the future since I took care to not modify data in the JTAGLOCK_KEY location. Also, per section 1.11.2 in the document you suggested, there are protection registers that must be set to even access the protection key. I did not modify these registers (not sure if the template BSL code did something to them.) Is it possible that re-mapping the memory triggered some sort of security mechanism that locked the device, even if the JTAGLOCK_KEY section was untouched?

    Thank you,

    svl123

    EDIT: I just noticed that my BSLOF section origin has a typo - it should start at 0x1800, not 0x1880 and this causes it to overlap with the RAM section. However, only 0xa4 bytes are used in BSLOF so it should not have written anything to RAM and caused a problem, right?

  • 0 in reply to svl123
    TI__Guru 56685 points
    Hello svl123,

    Yes, there are protection bits present. these bits are there to prevent you from accidentally writing over the BSL area when programming or doing a Mass erase or something. However, if you are already writing to the BSL area (as you are doing when placing the BSL on the chip), these bits are cleared.

    Without knowing exactly what happened, or what was written in that memory address, there is nothing I can suggest for you to prevent this happening again. What I can suggest is to make sure you can get into either the BSL or JTAg connection while you are doing your development. You should still be able to get into the device BSL via HW Entry, unless you have gotten rid of that specific check sequence within the BSL code (located in the BSL low level init file I think).
  • 0 in reply to Jace H
    Intellectual 690 points
    Ok, thank you. I will investigate the code further to see if there's anything I can find out about why the device has been secured.

**Attention** This is a public forum