• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 78 subscribers
  • Views 11887 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.

MSP-EXP430FR5969: An accident caused a JTAG lockout, need help recovering

Matthew Bohman
Prodigy 130 points
Part Number: MSP-EXP430FR5969
Other Parts Discussed in Thread: MSP430FR5969, MSP-FLASHER, MSP430F5528

Hi all,

I'm working on a project where I'm randomly changing registers while a program executes to see the effect on program execution. I've been using the same board for many, many iterations of this. However, I came to check on my MSP430FR5969 board today and found that this message has popped up: "SEVERE: MSP430: Error connecting to the target: The Debug Interface to the device has been secured". It doesn't let me program the board or communicate with it in any way. The board has been programmed thousands of times with this specific program and this is the first time anything like this has happened. I obviously can't trace the program execution back to the time of failure to diagnose the problem, so I'm looking for a way to recover my board. 

From these two threads I'm thinking that an unlucky change tripped the JTAG fuse and disabled the interface. I checked a few threads and found out that people have used the BSL_scripter tool to issue a mass reset to the board, which apparently should clear the JTAG fuse. However, I can't seem to make any progress at all with this. I've tried versions 3.1 and 3.2.1 of BSL_scripter. I've attached the script that I'm uing at the bottom of this post. Version 3.1.0 reports that each command executed successfully, but I still get the error about the the debug interface being secured when I try to program the MSP430. I've pasted that log file below. When I try anything in version 3.2 every command returns "[ACK_ERROR_MESSAGE]Unknown ACK value!". I've tried to erase it using by using MASS_ERASE as well as sending the wrong password. Additionally, when I try to read memory it only reads 0's instead of the data I just wrote to it, or FFs if it were protected memory. 

I'm developing on Ubuntu 16.04 and I've been using the ezFET on the development board. I haven't moved any jumpers. Am I approaching this the right way? Is there something that I'm missing? Please let me know, I would like to use my board again!

Thank you,

Matthew Bohman

LOG
MODE msp430frxx UART 9600 /dev/ttyACM0
RX_PASSWORD pass32_wrong.txt
DELAY 2000
RX_PASSWORD pass32_default.txt
RX_DATA_BLOCK blinkLED_FR6989.txt
TX_DATA_BLOCK 0x4400 0x00C0 Read_1.hex
TX_DATA_BLOCK 0xff80 0x0020 Read_2.hex
TX_DATA_BLOCK 0xffcc 0x0036 Read_3.hex
CRC_CHECK 0x4400 0x0020
SET_PC 0x4400

---------------------------------------------------------
BSL Scripter 3.1.0.0
PC software for BSL programming
2017-May-22 15:49:53
---------------------------------------------------------
Input file script is : /home/ecenstudent/Downloads/BSL_Scripter_Linux_3.1/ScriptExample/FRxx_uart/script_FRxx_uart.txt
//MODE FRxx UART 9600 /dev/ttyACM0
//MASS_ERASE
MODE msp430frxx UART 9600 /dev/ttyACM0
RX_PASSWORD pass32_wrong.txt
Read Txt File : /home/ecenstudent/Downloads/BSL_Scripter_Linux_3.1/ScriptExample/FRxx_uart/pass32_wrong.txt

DELAY 2000


RX_PASSWORD pass32_default.txt
Read Txt File : /home/ecenstudent/Downloads/BSL_Scripter_Linux_3.1/ScriptExample/FRxx_uart/pass32_default.txt

RX_DATA_BLOCK blinkLED_FR6989.txt
Read Txt File : /home/ecenstudent/Downloads/BSL_Scripter_Linux_3.1/ScriptExample/FRxx_uart/blinkLED_FR6989.txt
Time elapsed of writing 262 bytes : 15 seconds
Speed of writing data :0.01706(kB/s)

TX_DATA_BLOCK 0x4400 0x00C0 Read_1.hex
Write Txt File : /home/ecenstudent/Downloads/BSL_Scripter_Linux_3.1/ScriptExample/FRxx_uart/Read_1.hex
Tx Data Block intended num of bytes : 192
Time elapsed of reading 192 bytes : 5.001 seconds
Speed of reading data : 0.03749(kB/s)

TX_DATA_BLOCK 0xff80 0x0020 Read_2.hex
Write Txt File : /home/ecenstudent/Downloads/BSL_Scripter_Linux_3.1/ScriptExample/FRxx_uart/Read_2.hex
Tx Data Block intended num of bytes : 32
Time elapsed of reading 32 bytes : 5.001 seconds
Speed of reading data : 0.006249(kB/s)

TX_DATA_BLOCK 0xffcc 0x0036 Read_3.hex
Write Txt File : /home/ecenstudent/Downloads/BSL_Scripter_Linux_3.1/ScriptExample/FRxx_uart/Read_3.hex
Tx Data Block intended num of bytes : 54
Time elapsed of reading 54 bytes : 5.001 seconds
Speed of reading data : 0.01055(kB/s)

CRC_CHECK 0x4400 0x0020

SET_PC 0x4400
Set PC is sent.

  • 0
    Guru 33653 points

    There is no need to mess with BSL. Device can be mass erased by SBW / JTAG using mailbox system. Check erase options (TOTAL_ERASE  0x1B1B) for MSP-Flasher.

  • 0 in reply to zrno soli
    Prodigy 130 points

    Thanks for the reply! I tried the MSP430Flasher like you suggested, then did the ERASE_TOTAL option. However, nothing has changed. I've attached a screenshot of the output of the flasher. When I try to program the board it still gives me the same error ("The Debug Interface to the device has been secured") as before. I found this thread where somebody else got this same error, but it doesn't look like they found a solution either. 

  • 0 in reply to Matthew Bohman
    Guru 33653 points

    You are right. However, it is reported that unlocking with MSP-Flasher is working fine on FR4133.

    https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/335334/1373817#1373817

    I can unlock FR4133 / FR5959 using my flasher, but never tried FR5969.

  • 0 in reply to zrno soli
    Prodigy 130 points
    MSPFlasher claims to have performed a total erase, so the lock bits should have been cleared. Do you think that there is a possibility that something else is broken and the JTAG interface went down with it? This just happened to another board, so my best guess is that I reprogrammed the board at a bad time instead of writing to the lock bits.
    I've tried the BSL and MSPFlasher, are there any other approaches for recovering boards that have gone into an unknown state?
  • 0 in reply to Matthew Bohman
    Guru 33653 points

    Matthew Bohman said:
    MSPFlasher claims to have performed a total erase, so the lock bits should have been cleared.

    USER CODE / TOTAL ERASE will set complete FRAM location to (factory value) 0FFh, not only lock bits. If device was locked by bad program it should be unlocked because bad program is wiped-out.

    MSP-Flasher will store ERASE message to mailbox, and check after POR if everything is OK ("claims") by get device SBW / JTAG entry sequence.

    Matthew Bohman said:
    Do you think that there is a possibility that something else is broken and the JTAG interface went down with it? This just happened to another board, so my best guess is that I reprogrammed the board at a bad time instead of writing to the lock bits.
    I've tried the BSL and MSPFlasher, are there any other approaches for recovering boards that have gone into an unknown state?


    What is "reprogrammed the board at a bad time"? I guess that you running FR devices on VCC higher than 2V. There is no other options than "erasing" (reported as) locked device by SBW / JTAG mailbox or by BSL. I used forced SBW (with ignoring JTAG errors) for unlocking flash devices (reported fuse blown, but it was not), but this option is not exist for TI tools.

  • 0 in reply to zrno soli
    Prodigy 130 points
    First, thank you so much for your help! I really appreciate it.

    I think I understand what the tools are doing better now. If the problem is persisting after using those tools then there isn't much more that I can do for the processor. Is it possible for the ez-FET portion of the dev board to be locked instead of the FR5969? It looks like the board has an MSP430F5528 on that side. I just disconnected the power from the FR5969 by removing a jumper on the board. When I tried to program the board it still gave me the message about the debug interface being secure, instead of an error on not finding the board.
  • 0 in reply to Matthew Bohman
    Guru 33653 points

    Matthew Bohman said:
    First, thank you so much for your help! I really appreciate it.

    I think I understand what the tools are doing better now. If the problem is persisting after using those tools then there isn't much more that I can do for the processor. Is it possible for the ez-FET portion of the dev board to be locked instead of the FR5969? It looks like the board has an MSP430F5528on that side. I just disconnected the power from the FR5969 by removing a jumper on the board. When I tried to program the board it still gave me the message about the debug interface being secure, instead of an error on not finding the board.

    No, this is not correct test, because device still can be powered by TEST / RESET SBW signals, or confuse FET somehow. For testing FET, target device must be disconnect completely (RESET and TEST in High-Z) by jumpers. In this case FET should report not finding target device.
    I guess that there is some problem inside DLL (TI debug stack) regarding unlocking FR5969. Simple solution, you send to TI TXT / HEX file that cause problems, and they test unlocking on their side with same setup.
    As I already mention, don't have this device. In other case I will test my flasher with your locking program, and report here.
  • 0 in reply to zrno soli
    Prodigy 130 points

    zrno soli said:

    No, this is not correct test, because device still can be powered by TEST / RESET SBW signals, or confuse FET somehow. For testing FET, target device must be disconnect completely (RESET and TEST in High-Z) by jumpers. In this case FET should report not finding target device.

    You're right. I disconnected the jumpers and tried to program it. The error about the debug interface went away, to be replaced with a message about an unknown device. The tty port is still enumerated, however, so I assume that the FET is working as expected. 
    zrno soli said:
    I guess that there is some problem inside DLL (TI debug stack) regarding unlocking FR5969. Simple solution, you send to TI TXT / HEX file that cause problems, and they test unlocking on their side with same setup.
    As I already mention, don't have this device. In other case I will test my flasher with your locking program, and report here.

    Unfortunately, the error isn't reproducible. My base code works properly. For my application I am running a script that flips bits at random during execution to test how they affect the program. The script ran over ten thousand times, then suddenly got an error of "SEVERE: MSP430: Trouble Halting Target CPU: Internal error". The script timed out after that, then I couldn't program the board afterwards. I don't know what specifically caused the lockup. 

    I decided to test the board on a Windows machine in the hopes that the DLL for MSP Flasher might be a little different. It allowed me to update the firmware, but didn't change anything else. Are there any other options to fix this? I could get a JTAG breakout for the board, but I don't think that will change anything. 

  • 0 in reply to Matthew Bohman
    Guru 33653 points

    Here is attached script that I used for unlocking FR5739 by BSL. However, don't know if BSL can be internally disabled for FR5969.

    6813.MSP430FR5739_BSL_Fuse.rar

  • 0 in reply to zrno soli
    Prodigy 130 points

    Thank you for the script! I changed the first line, then ran it using version 3.2.1. Each command returned  "[ACK_ERROR_MESSAGE]Unknown ACK value!". Someone else had the same issue https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/584603/2150471, so I tried an older version of the scripter (3.1.0). I attached the output below, but I still can't program the board. It seems like this is known to happen with the MSP430FR5969. 

  • 0 in reply to Matthew Bohman
    Guru 33653 points

    Just to clarify FRAM "erasing" by mailbox system.

    I was wrong about TOTAL_ERASE. While ERASE_USER_CODE will unlock and "erase" locked FR4133 (or similar device), TOTAL_ERASE will "erase" only unlocked FR5959 (or similar device). TOTAL_ERASE will not "erase" or unlock locked device.

    I unlock locked FR5959 (or similar device) by BSL. I use (guess too old) BSL Scripter v 1.07 with script, that is already attached in previous post.

    • **Attention** This is a public forum