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.

JTAG Fuse Blown during downloading code to MSP430F5506

Other Parts Discussed in Thread: MSP430F5506

Hi!

I wanted to find ways to erase the BSL of chip MSP430F5506. So I modified one of example code from TI and built the project and tried to download the image of the program flashWrite.out to the CPU via the MSP-FET430UIF. We are using Code Composer Studio version: 4.2.3.00004.  The BSL write and erase was enabled. But during downloading the program, a message occurred saying :

“Error connecting to the target:

Could not access device - security fuse is blown”

Below is the C file and part of the link.cmd.

Is the fuse really blown?

How can I work around this?

Thank you.

Tracie

C file:

#include <msp430f5506.h>

 

void main(void)

{

  unsigned long * Flash_ptrD;               // Initialize Flash pointer Seg D

// unsigned long value;

  WDTCTL = WDTPW+WDTHOLD;                   // Stop WDT

  SYSBSLC = 0x0003;            // ensure BSL area is open

  Flash_ptrD = (unsigned long *) 0x1000;    // Initialize Flash pointer

// value = 0xC35A;                       // Initialize Value

  FCTL3 = FWKEY;                            // Clear Lock bit

  FCTL1 = FWKEY+ERASE;                      // Set Erase bit

  *Flash_ptrD = 0;                          // Dummy write to erase Flash seg

  FCTL1 = FWKEY+BLKWRT;                     // Enable long-word write

// *Flash_ptrD = value;                      // Write to Flash

  FCTL1 = FWKEY;                            // Clear WRT bit

  FCTL3 = FWKEY+LOCK;                       // Set LOCK bit

  while(1);                                 // Loop forever, SET BREAKPOINT HERE

}

 

Link.cmd

    BSL_ZAREA               : origin = 0x1000, length = 0x0010

    BSL0                    : origin = 0x1010, length = 0x01F0

    BSL1                    : origin = 0x1200, length = 0x0200

    BSL2                    : origin = 0x1400, length = 0x0200

    BSL3                    : origin = 0x1600, length = 0x01F0

    BSL_SIG                 : origin = 0x17F0, length = 0x000C

    JTAG_LOCK               : origin = 0x17FC, length = 0x0004

  • Yes, the "fuse" is blown (figuratively).

        JTAG_LOCK               : origin = 0x17FC, length = 0x0004

    That 32-bit JTAG_LOCK is the JTAG "Fuse". If not all "1" nor all "0", the "fuse" is "blown".

    If the BSL still works, you can down-load a program to write all "0" to those 32-bits and the "fuse" is "un-blown" again.

  • I'm wondering why the programmer would have written a locking value to that longword.

    1. I see that the source code has linker segment defined for JTAG_LOCK, so maybe some code somewhere (not posted) puts data into that segment.
    2. Maybe there a setting in the programmer that says "lock JTAG"?  If so, maybe you had it set?
    3. The linker probably has a "fill unused memory" option, and maybe you had it set up to fill with something other than 0x00 and 0xFF.

    My other question is that the code you posted doesn't seem to be a bootstrap loader.  Are you just experimenting with erasing the bootstrap loader via your own code?

    Jeff

  • Thank you Old_cow_yellow. One of our "fuse-blown" chip became alive using the method you mentioned. But the other  chip that became fuse-blown during JTAG programming can't be "un-blown" yet. Maybe this is because  the whole flash were erased.before the JTAG programming. 

  • Jeff Tenney said:

    I'm wondering why the programmer would have written a locking value to that longword.

    I don't think that longword has been written.

    1. I see that the source code has linker segment defined for JTAG_LOCK, so maybe some code somewhere (not posted) puts data into that segment.

    We were very careful not to write on the JTAG_LOCK region. Some other small program with the same linker file don't cause this "fuse-blown" problem.

         2.     Maybe there a setting in the programmer that says "lock JTAG"?  If so, maybe you had it set?

    No. I have checked.

        3.    The linker probably has a "fill unused memory" option, and maybe you had it set up to fill with something other than 0x00 and 0xFF.

    As answered for the first question.

    My other question is that the code you posted doesn't seem to be a bootstrap loader.  Are you just experimenting with erasing the bootstrap loader via your own code?

    Yes. But the chip got "fuse-blown" during JTAG downloading the code to the chip.

    Jeff

     

  • Jeff Tenney said:

    I'm wondering why the programmer would have written a locking value to that longword.

    I don't think that longword has been written.

    1. I see that the source code has linker segment defined for JTAG_LOCK, so maybe some code somewhere (not posted) puts data into that segment.

    We were very careful not to write on the JTAG_LOCK region. Some other small program with the same link file don't cause this "fuse-blown" problem.

         2.     Maybe there a setting in the programmer that says "lock JTAG"?  If so, maybe you had it set?

    No. I have checked.

        3.    The linker probably has a "fill unused memory" option, and maybe you had it set up to fill with something other than 0x00 and 0xFF.

    As answered for the first question.

    My other question is that the code you posted doesn't seem to be a bootstrap loader.  Are you just experimenting with erasing the bootstrap loader via your own code?

    Yes. But the chip get "fuse-blown" during JTAG downloading the code to the chip.

    Jeff

     

  • Tracie Huang said:

    I don't think that longword has been written.

    <snip, snip>

    But the chip get "fuse-blown" during JTAG downloading the code to the chip.

    It's one or the other.  Either the longword at 0x17FC was not written (your first statement above) or the JTAG fuse was blown (your second statement above).  Both cannot be true.  The content of that longword is the JTAG fuse.

    In your case, I think the true statement is the first one.  The JTAG fuse is not blown.  I think CSpy is giving you the wrong error message.

    Instead, I think your experiment actually worked!  You erased the first segment (0x1000 to 0x11FF).  Now when the device boots up, it gets confused right away and probably resets again immediately, frustrating the JTAG tool which is trying to attach.  I have seen a few threads on this forum where people install really bad code that causes some kind of reset right away have lots of trouble getting JTAG to attach.  I don't understand it, but it does seem to happen.  You may want to search the forum for tricks on how to get JTAG access back when rotten code is installed.  (In my opinion the FET driver ought to do a better job of seizing control of the target.)

    As a reference, here's a diagram from slaa450a showing the relevant parts of the boot process.  I think your BSL Protect Function is probably erased / nonfunctional.

    Jeff

  • Jeff Tenney said:
    You erased the first segment (0x1000 to 0x11FF).  Now when the device boots up, it gets confused right away and probably resets again immediately

    Well possible: the last BSL segment doe snot hold the JTAG fuse only. It also holds the BSL signature (is there one?) and a vector to the BSL entry check function (@0x17f2).
    If this function was in the first BSL segment and it was erased, then in the diagram you posted, the PC is set to 0xffff and this will cause a (more or less immediate) reset (due to access violations). Which repeats the procedure.

    If you're lucky, you can (with try and error, manual resets etc.) perhaps get a (very small) window where the JTAG can attach to the device between resets. Then you should have a (working) BSL code at hand to repair it, or erase the last BSL sector with the BSL signature. It's a very small time window, fi at all. Other wise the MSP is gone. There's a reason why the BSL is protected :)

  • In my first post, I did not have a chance to run the program to erase the first segment of the BSL yet since the "fuse" got "blown" during using JTAG downloading the built file to the MCU.

  • Hi Tracie,

    Did you by chance build your test code in a project meant as a bootstrap loader?

    Tracie Huang said:

    The BSL write and erase was enabled.

    What does this mean?  Are you referring to configuration settings in the project?

    Jeff

  •  

    Jeff Tenney said:

    Hi Tracie,

    Did you by chance build your test code in a project meant as a bootstrap loader?

    No.

    The BSL write and erase was enabled.

    What does this mean?  Are you referring to configuration settings in the project?

    Yes.

    Jeff

    [/quote]

  • So you told your project to erase the BSL before flashing in your test code?

  • Jeff Tenney said:

    So you told your project to erase the BSL before flashing in your test code?

    Yes. This means the whole flash had been erased before JTAG tried to download the built code to the CPU.

  • Tracie Huang said:
    So you told your project to erase the BSL before flashing in your test code?


    Yes. This means the whole flash had been erased before JTAG tried to download the built code to the CPU.[/quote]

    In this case, the BSL signature should be gone and the JTAG fuse should be reset too (and therefore JTAG should be active). The problem is that since no BSL is found and no applicaiton is on the chip, the chip might go into LPM immediately. You can try to attach a reset pushbutton to the MSP and try flashing while pressign the rteset button immediately after starting the flas process. This might sooner or later lead to a JTAG connection. Or never.
    Alternatively buy a new MSP. It's cheaper than spending too much time for the rescue of a more or less dead chip.

**Attention** This is a public forum