MSP430F5529 Launchpad Not Connecting To Target; Unknown Device

Michael,

Sounds like there may be a connection issue between the EZFET and the F5529.  Since you mention having many LaunchPads, I'm assuming that you have double and triple checked the jumpers on the programming interface to ensure GND, 5V, 3V3, SBW RST, and SBW TST were all connected.

If you have a second F5529 LaunchPad, you can use one the EZFET on one LP to program the device on the other LP.  Just use wire jumpers to connect the top pin of the above signals on one LP to the bottom pin of the above signals on the other LP.  Doing this both ways with the two LPs will help you isolate the issue and potentially try to debug it.

If you have two boards: A (failing board), and B (working board), here are the tests:

1. EZFET_A programming F5529_A - this should be a known failing case
2. EZFET_B programming F5529_B - this should be a known working case
3. EZFET_A programming F5529_B
4. EZFET_B programming F5529_A

Depending on which of tests 3 and 4 fail, we should be able to determine if the problem is with the EZFET or the F5529 on the failing launchpads.  If test 3 fails, but 4 passes, then the problem is in the EZFET.  If test 4 fails, but test 3 passes, then the problem is with the target F5529.

Please post back the results of this test and we can help debug from here.

Mike

Dear Mr. Pridgen;

Please excuse the formality of addressing you by your last name. I did this because our future correspondences may become confusing to other readers and, possibly, each other , as we are both named "Mike".

I "hot wired" the good unit, B, to the bad board, A, and I received an interesting response. I will try to upload what I saw on my computer screen when I tried to download a program using debug in CCS6. I can't upload anything now because this webpage does not offer me the "insert" option. When I attempt to edit this message then the insert option may open up for me.

In any case, in a nutshell, I received a message in telling me that a "security fuse" had been blown on when I hot wired the known working FET jumpers to the bad MSP430F Launchpad board. There existed an initial ancilliary issue with regard to my MSP430 USB firmware needing to be updated and also a driver. This happened because the good Launchpad, B, had its firmware and USB driver modified when I was conducting another project. I would ignore these messages.

I believe my easiest solution for me would be to try to use the BSL to do a mass erase. Can you point me to a binary TI.txt file or other solution, that I can download to the MSP430 and remedy this problem? However, you may know of a better solution, or troubleshooting method and I would like to hear your opinion first.

I managed to get into edit mode, here are the screenshots:

Hi Mr. Choi,

If you refer to me as Mr. Pridgen, then its only logical that I should refer to you as Mr. Choi ;)

Just for the sake of ensuring your test setup is correct, did you try using the EZFET on the failing LaunchPad to program the F5529 on the good LP?  This should work, but is worth testing to make sure your setup/procedures are good.

You can use the USB BSL to restore the JTAG lock bits on the F5529, assuming that is actually the issue.  Sometimes if the connection is bad between the EZFET and the target device, it will report the same error.  This is why the above test is important, as it verifies your test setup is ok.  Something as simple as the wires being too long (adds too much capacitance) could prevent the JTAG/SBW communication from working correctly, which will sometimes respond with the fuse blown error.

To use the USB BSL to try to restore JTAG functionality, you want to use the Python_Firmware_Upgrader available with CCS.  This can be found in the Resource Explorer (View -> Resource Explorer), then navigating to MSP430ware -> Libraries -> USB Developers Package -> Firmware Updater.  Alternatively, you could use the BSL_Scripter available in the SLAU319.zip package for a command line interface to the BSL.  This older post has some good info in it (particularly later in the post) about how to restore JTAG functionality through the BSL.

As mentioned in the linked post, the problem may be that the application loaded into the device may be crashing and resetting immediately every time it runs (constantly repeating this).  If this is the case, JTAG will sometimes not be able to connect and could return the fuse blown message.  Erasing the firmware (or at least the reset vector to 0xFFFF) will fix this problem.

Take a look at the USB BSL tools and see if you can use any of those to restore functionality.

Mike Pridgen

Dear Mr. Pridgen;

      I connected the EZFET jumpers from the failing Launchpad onto the input jumpers of the good Launchpad and the MSP430F on the good Launchpad was able to be programmed.

      There appears to be hope for the failing Launchpad MSP430F.

       I am new to using the BSL.    I installed the Python Firmware Upgrader a few weeks ago but I have not had much time to get acquainted with any maintenance tools or programs that can reset my MSP430F to its original state.   I became better acquainted with the variables of the problem at hand when I read the post that you had linked me to.   However, I do believe that TI should have a working solution for this problem that its technicians and engineers would use regularly.  

       Can you point me to the TI binary text files that can be used by the Python Firmware Upgrader which can solve this problem?  If there is no code available that can be used by Python Firmware Upgrader, I can also use FET-Pro430.

       I would like to thank you for your excellent technical support and I look forward to reading your next reply. 

Mr. Choi,

The Python Firmware Upgrader requires you to load a hex image (ti-txt format) and doesn't give you the option to just mass erase the device.  With the BSL Scripter, since you actually control which commands get sent, you can just issue a mass erase without downloading any more firmware.

Also, if the issue (as we suspect) is the code constantly resetting, you can load a new firmware image with the BSL, as long as it is a known good image.  I recommend taking one of the code examples, set CCS to build a hex image out of it, and use that image.

What we (TI) generally do is use the BSL_Scripter and modify the script to just issue a mass erase.  This is an example of a script for a FRxxxx device with a UART BSL.  Modifying this to use the USB BSL should be very straightforward with the documentation included with the BSL_Scripter.

MODE FRxx UART COM101
VERBOSE
RX_PASSWORD 
DELAY 1000
MASS_ERASE

Mike

Dear Mr. Pridgen;

      Thank you for your excellent technical support. 

       I followed you instructions and this is what happened:

The Python software worked as expected and downloaded the *.txt (Ti-text file) to the MSP430F Launchpad.   The MSP430F accepted the program and ran as expected. 

I then tried to download another program into the MSP430F using the CCS6 IDE and I received the error message that the security fuse was blown and the debugger could not connect to the target.  

       Before, this experiment I tried using the MSP430_Flasher and the program worked once and then never worked again.   The program just opens and closes whenever I click on it.   However, when I click on the "MSP430 Example" (this program comes bundled with the MSP flasher program and I believe it is a *.bat file (batch file)), this example program runs and doesn't close immediately.   The program tells me that it is trying to access the MSP430F, the program detects that the security fuse is blown, and then the program closes the MSP430F driver.    Therefore, the interfacing program that we must use must be a very low level program. 

        I am uncertain if the BSL_Scripter program is low level  enough to remedy this problem.   However, I am willing to try it.   I did download and install the program, however, I can't find a simple tutorial that will show me how to use this program.    Perhaps, you can link me to a tutorial with pictures.

        I believe that only TI can tell me if the BSL_Scripter program is low level enough to erase and re-install a completely new system or is programmed  in such a way as to bypass the blown security fuse check.    Hopefully, you will know the answer to this question.   

        If the BSL_Scripter is low level enough to accomplish the task at hand, can you please link me to a working file that you had used.   This way we are on the same page and there will exist fewer variables to consider with regard to your test set up and mine.

         Again, I would like to wish you a happy new year and I am most grateful for your excellent technical support.

Hi Mr. Choi,

The BSL_Scripter isn't any "lower level" than the other BSL tools (such as the python firmware upgrader), it just gives you direct access over each command the BSL host sends.  For a list of all the BSL commands, take a look at the BSL User's Guide and go to the USB section.  For some guidance on how to use the BSL_Scripter, take a look at the User's Guide included in the directory.  The BSL_Scripter is a command line executable and requires command line arguments to define the settings.

The script I posted several posts ago is the script you need to run with the BSL_Scripter to perform a mass erase.  Take a look at the BSL_Scripter documentation that explains how to use the tool, then configure it to run the above script, then try it out.  Once the device is mass erased, try again with JTAG to connect to the device.

Let me know what your results are.

Mike

Dear Mr. Pridgen;

I wrote a program for the BSL Scripter, however, I don't believe that the program worked at all.

The MSP430F had a blink LED program loaded onto it before the BSL Scripter program was utilized. After running an erase memory program, the blink LED program remained on the MSP430F.    When I plugged the MSP430F into the USB port and started CCS6, the debug program told me my security fuse was still blown.
 
Below is a copy of the data returned to me by BSL Scripter:

---------------------------------------------------------
BSL Scripter 3.1.0.0
PC software for BSL programming
2016-Jan-12 19:33:21
---------------------------------------------------------
Input file script is : C:/Users/account_4/Desktop/BSL Scripter/BSL_Scripter_Windows/script_1.txt
MODE 5xx USB
VERBOSE


DELAY 1000


TX_BSL_VERSION
[19]
<3b> <07> <57> <4c> <57>

MASS_ERASE
[15]
<3b> <07>

ERASE_SEGMENT 0x004400
[12] [00] [44] [00]
<3b> <07>

ERASE_SEGMENT 0x0243FF
[12] [ff] [43] [02]
<3b> <07>

Can you please tell me what information is denoted in the brackets [ ] with respect to the ERASE_SEGMENT command and what does <3b> <07> mean?

Can you please correct my program? Also, I tend to believe there must exist a *.txt file which contains the original firmware and operational code so that the MSP430F can function. In other words, if I bought a brand new MSP430F direct from TI, the IC I open in the package would have this firmware installed onto it. Can you please email me (or post) the code so that I can just overwrite any corrupted data?

Thank you for your past efforts.

The numbers in brackets are BSL core commands; see section 3.5 of SLAU319.

<3b><07> is the answer, as described in section 3.7. In this case, all answers are "unknown command".

You need to send a password before the BSL allows anything. (If you send a wrong password, the BSL does a mass erase, which also resets the password to all ones. If you don't know the password, just send an all-ones password twice.)

As shown in section 5.5, the F5529's built-in BSL does not support any useful commands; you have to download a full BSL into RAM first. (In the 5xx_usb example of the BSL Scripter, you see that it downloads RAM_BSL_USB.txt first before downloading the actual firmware.)

A brand-new F5529 has no actual firmware; all that is has is the internal BSL (which yours still has; otherwise, it would not be able to send answers).

Dear Mr. Ladisch;

     I am very grateful for the information you wrote.

     I am new to the BSL Scripter and the BSL.   This was my first program and as you can see, I need help.   When you wrote:

"You need to send a password before the BSL allows anything. (If you send a wrong password, the BSL does a mass erase, which also resets the password to all ones. If you don't know the password, just send an all-ones password twice.)"

      Can you please cut and paste the code that you used  to send the "all ones password" to the BSL from an old program that you used?    Believe it or not, for someone who has never programmed using the BSL scripter what you wrote can have many interpretations and, therefore, there are many ways possible methods to do the task you had described.  However, there is probably only one correct way to do this.   If you posted the actual commands that you used, using the BSL scripter, it would be appreciated.  

      Again, I would like to thank you for your post.

The all-ones password is shipped as pass32_default.txt. This is what the example script does:

//
//Script example 5xx USB BSL
//Device tested: MSP430F5529
//
//Download a blink LED application
//to the device through the USB BSL
//
LOG
////////////////////////////////////
//Write RAM USB BSL to the device
////////////////////////////////////
MODE 5xx USB
//gives wrong password to do
//mass erase in the memory
RX_PASSWORD pass32_wrong.txt
RX_PASSWORD pass32_default.txt
RX_DATA_BLOCK_FAST RAM_BSL_USB.txt
SET_PC 0x2504
DELAY 3000
////////////////////////////////////
//Start the RAM USB BSL application
//to download the blink application
////////////////////////////////////
MODE 5xx USB
RX_PASSWORD pass32_default.txt
RX_DATA_BLOCK blinkLED_f5529.txt
SET_PC 0x4400

Dear Mr. Ladisch and Mr. Pridgen;

     I erased the sections of memory that were referenced by Mr. Pridgen.

"This means only code memory is erase, which if we check the memory organization table in the F5529 Datasheet (section 6.4), we see it is from 0x004400 to 0x0243FF."

ERASE_SEGMENT 0x004400

ERASE_SEGMENT 0x0243FF

      I am uncertain about how the erase segment command operates.  One would think that there should exist a start erase address and a stop erase address, hence, the two commands.   But can you tell me exactly how the ERASE_SEGMENT command works?   Does referencing one address in a segment, erase the entire segment, even if that one address is located somewhere in the middle of the segment?

      Afterward, I connected the Launchpad to the CCS6 debugger and the same error error message was returned, "security fuse blown".

     Can anyone explicitly tell me the next commands that I need to utilize to remedy my problem?

     I would like to thank you for your past replies.

I tried the example script numerous times using BSL scripter and BSL scripter would just open and close. If there is a way to keep the window open, I would like to know it.

However, I did manage to get the example script to run once and this was the output:

---------------------------------------------------------
BSL Scripter 3.1.0.0
PC software for BSL programming
2016-Jan-14 17:42:32
---------------------------------------------------------
Input file script is : C:/Users/account_4/Desktop/BSL Scripter/BSL_Scripter_Windows/script_5xx_usb.txt
////////////////////////////////////
//Write RAM USB BSL to the device
////////////////////////////////////
MODE 5xx USB
//gives wrong password to do
//mass erase in the memory
RX_PASSWORD pass32_wrong.txt
Read Txt File : C:/Users/account_4/Desktop/BSL Scripter/BSL_Scripter_Windows/pass32_wrong.txt

RX_PASSWORD pass32_default.txt
Read Txt File : C:/Users/account_4/Desktop/BSL Scripter/BSL_Scripter_Windows/pass32_default.txt
Password is correct.
RX_DATA_BLOCK_FAST RAM_BSL_USB.txt
Read Txt File : C:/Users/account_4/Desktop/BSL Scripter/BSL_Scripter_Windows/RAM_BSL_USB.txt
Time elapsed of writing 3328 bytes : 0.14 seconds
Speed of writing data :23.21(kB/s)
BSL ACK is received.
SET_PC 0x2504
Set PC is sent.
DELAY 3000


////////////////////////////////////
//Start the RAM USB BSL application
//to download the blink application
////////////////////////////////////
MODE 5xx USB
RX_PASSWORD pass32_default.txt
Read Txt File : C:/Users/account_4/Desktop/BSL Scripter/BSL_Scripter_Windows/pass32_default.txt
Password is correct.
RX_DATA_BLOCK blinkLED_f5529.txt
Read Txt File : C:/Users/account_4/Desktop/BSL Scripter/BSL_Scripter_Windows/blinkLED_f5529.txt
Time elapsed of writing 230 bytes : 0.02 seconds
Speed of writing data :11.23(kB/s)
Data received by BSL.
SET_PC 0x4400
Set PC is sent.

Now the bad news. I plugged my msp430f Launchpad into the CCS6 debugger and the message that the security fuse is blown - cannot connect to target - is returned.

I tend to believe that all these steps were unnecessary. Why can't someone just send me the original msp430f *.txt file that is installed at the factory and over write everything (or, in the alternative, send me a *.txt file that will remedy the blown security fuse issue)?

If these proposed solutions are not feasible, can someone please tell me why they are not feasible?

The BSL scripter is meant to be run from the command line.

Additionally, the BSL must be running. The safest way to do this is to re-plug the LaunchPad with the BSL button pressed.

Please copy this into the file sysbslc.txt :

@182
03 00 
q

and copy this into a script file:

MODE 5xx USB
RX_PASSWORD
RX_PASSWORD
RX_DATA_BLOCK_FAST RAM_BSL_USB.txt
SET_PC 0x2504
DELAY 3000
MODE 5xx USB
RX_PASSWORD
RX_DATA_BLOCK sysbslc.txt
TX_DATA_BLOCK 0x17fc 0x4 lockbits.txt

These two files and the file RAM_BSL_USB.txt must be in the same directory. Execute the BSL scripter with the script file.

What are the contents of the resulting lockbits.txt file?

I tend to believe that all these steps were unnecessary.

We don't yet know what the problem is.

Dear Mr. Ladisch;

     I would like to thank you very much for your help. 

     The lockbits.txt file contains this information:

@17fc
AA AA AA AA
q

      I hope you find this information helpful.   I look forward to reading your reply.

This value shows that the JTAG interface was deliberately disabled. Section 1.4.2.1 of SLAU320 says:

In contrast to the 1xx, 2xx, 4xx families, which require special handling to burn the JTAG security fuse, the 5xx and 6xx families' JTAG is locked by programming a certain signature into the devices' flash memory at dedicated addresses. The JTAG security lock key resides at the end of the bootstrap loader (BSL) memory at addresses 0x17FC to 0x17FF. Any value other than 0 or 0xFFFFFFFF programmed to these addresses irreversibly locks the JTAG interface. All of the 5xx and 6xx MSP430 devices come with a preprogrammed BSL (TI-BSL) code that, by default, protects itself from unintended erase and write access. This is done by setting the SYSBSLPE bit in the SYSBSLC register of the SYS module (see the MSP430x5xx and MSP430x6xx Family User's Guide (SLAU208) SYS Module chapter for details). Because the JTAG security lock key resides in the BSL memory address range, appropriate action must be taken to unprotect the memory area before programming the protection key. This can be done by a regular memory write access as described in Section 1.3.3.2 by writing directly to the SYSBSLC register address and setting the SYSBSLPE to 0. Afterward, the BSL memory behaves like regular flash memory and a JTAG lock key can be programmed at addresses 0x17FC to 0x17FF as described in Section 1.3.4.2.

"Irreversibly" is wrong if the original BSL, which allows rewriting the lock bits, is kept.

To re-flash the original BSL with the lock bits cleared, get the original BSL firmware image. It can be found on the MSPBSL page, in the CUSTOM-BSL430 package, in the directory 5xx_6xx_Released_BSL_Images/MSP430F552x_550x_Family/USB BSL, as the file BSL.00.07.88.38.txt.

Copy that image file to the same directory as the sysbslc.txt file used earlier, and this script:

MODE 5xx USB
RX_PASSWORD
RX_PASSWORD
RX_DATA_BLOCK_FAST RAM_BSL_USB.txt
SET_PC 0x2504
DELAY 3000
MODE 5xx USB
RX_PASSWORD
RX_DATA_BLOCK sysbslc.txt
ERASE_SEGMENT 0x1000
ERASE_SEGMENT 0x1200
ERASE_SEGMENT 0x1400
ERASE_SEGMENT 0x1600
RX_DATA_BLOCK BSL.00.07.88.38.txt

At the moment, the BSL is the only way to access the chip; if anything goes wrong, it's bricked.
Mike Pridgen, can you confirm that this is the correct way to re-flash the BSL?

Dear Mr. Ladisch;

     I would like to thank you for your efforts. 

     Can you tell me, have you tested this program that you made on your MSP430F Launchpad?

     The reason why I am asking this question is because your program did not run in its entirety on my MSP430F.

      Also, when you wrote:

     "  Mike Pridgen, can you confirm that this is the correct way to re-flash the BSL? "

      I do believe that if you are asking questions about the correct way to re-flash the BSL, it is necessary for an experienced TI engineer  to send us some feedback because this is a very, very, sensitive operation.

      Mr. Ladisch, please do not try your program on your Launchpad until we read feedback from a TI engineer who has experience with this operation.   The reason why I am telling you this is because the condition of my launchpad went from bad to worse.    When you wrote:

"  At the moment, the BSL is the only way to access the chip; if anything goes wrong, it's bricked. "

      This may be the case...

The erase segment command was not completely transmitted.

This is the log results:  

Input file script is : C:/Users/account_4/Desktop/BSL Scripter/BSL_Scripter_Windows/MSP430F_BSL.txt
MODE 5xx USB
RX_PASSWORD
 Password is correct.
RX_PASSWORD
 Password is correct.
RX_DATA_BLOCK_FAST RAM_BSL_USB.txt
 Read Txt File  : C:/Users/account_4/Desktop/BSL Scripter/BSL_Scripter_Windows/RAM_BSL_USB.txt
 Time elapsed of writing 3328 bytes : 0.14 seconds
 Speed of writing data :23.21(kB/s)
 BSL ACK is received.
SET_PC 0x2504
 Set PC is sent.
DELAY 3000
 
 
MODE 5xx USB
RX_PASSWORD
 Password is correct.
RX_DATA_BLOCK sysbslc.txt
 Read Txt File  : C:/Users/account_4/Desktop/BSL Scripter/BSL_Scripter_Windows/sysbslc.txt
 Time elapsed of writing 2 bytes : 0 seconds
 Speed of writing data :1.#IO(kB/s)
 Data received by BSL.
ERASE_SEGMENT 0x1000
 
DELAY 2000
 
ERASE_SEGMENT 0x1200
 Data is not completely transmitted...

Can you tell me if you tried your program, or not, on your MSP430 Launchpad and can you connect to BSL_Scripter (download and upload programs)?

I tested the previous scripts, but not the last one.

The message "Data is not completely transmitted" indicates that the communication with the BSL over USB failed for some reason. (The BSL Scripter does not show the error code.)

The running BSL is executed from RAM, not from the flash at 0x1000, so I see no reason why erasing the first segment should break anything. It's possible that there is still some protection for the BSL flash, and that trying to erase it just reset the CPU. In that case, the first segment was not actually erased. Is the USB device still visible?

As OCY mentioned, there are definitely safer ways to unlock JTAG (assuming this is actually the issue).  The safest way is to modify the JTAG Lock bits in the BSL memory area, which is protected, so you need to unlock it first.  Create the following two scripts:

BSL_unlock.txt

@0182
03 00 
q

JTAG_unlock.txt

@17FC
00 00 00 00 
q

Then modify the script that you run with BSL_Scripter.exe (typically script.txt or similar), where the RAM_BSL version matches whatever version you are using:

MODE 5xx USB
// to erase device, should fail
RX_PASSWORD password.txt
RX_DATA_BLOCK_FAST RAM_BSL.00.08.08.38.txt
SET_PC 0x2504
DELAY 3000
//------------------------------------------------------
// The USB BSL is now in RAM, and is started
// We must now re-initialize communication
//------------------------------------------------------
MODE 5xx USB
//------------------------------------------------------
// Now we simply demo the use of the supported functions
//------------------------------------------------------
RX_DATA_BLOCK BSL_unlock.txt
RX_DATA_BLOCK JTAG_unlock.txt

BSL_unlock.txt modifies the register to unlock the BSL space (to make it available for modification.  JTAG_unlock.txt then modifies the JTAG protect bits to all 0s, which re-enables JTAG functionality.

Once you restore JTAG access, we recommend that you reflash the BSL using CCS to restore the JTAG lock fuse bits to 0xFFs.  Due to the nature of Flash (erases to '1's, and writes to '0's), if you want to potentially JTAG lock the device in the future, you need to reset the JTAG lock bits to all '1's, which can only be done by erasing the BSL section.  The safest way to erase/modify BSL memory is through JTAG access (so you always have access to the part through one mode (JTAG/BSL), while the other mode is getting reset.

Mike

Dear Mr. Pridgen;

      Thank you for your reply.

      Can you please explicitly identify the TI-txt file that you were referring to when you made this statement:

" reflash the BSL using CCS to restore the JTAG lock fuse bits to 0xFFs"

Also, can you go into detail with regard to the sequence of action which should be followed in CCS6?

       Again, I would like to thank you for your reply.

Dear Mr. Pridgen;

   Again, I would like to thank you for your past replies:

The reason why I posed this question:

Can you please explicitly identify the TI-txt file that you were referring to when you made this statement:

" reflash the BSL using CCS to restore the JTAG lock fuse bits to 0xFFs"

is because this program had just been run:

@17FC
00 00 00 00
q

This program enables the programmer to program the MSP430F.   Can you tell me the potential consequences if I leave the MSP430F in this state?  That is, if these are the JTAG fuse bits that you were referring to.

Also, does re-flashing the MSP430F in the CCS IDE result in some extra functions being performed that leave the MSP430F in a more stable state?