MSP430 Fuse Issue

Hi,

I cant answer question 1. since I did not have this kind of issues anymore and not as drastic (once I hit them, I simply soldered some parts wrong). Do you use a custiom board? Any chance that signals or power couple back to your FET that should not?

But for 2. there is no way to really reset the fuse since it is really blown. The only way to access and reprogram flash on a cpu with blown fuse is to use the bootstrap loader if available. In some devices the BSL is omitted for security reasons as far as I know. 

Jan Kesten said:

...But for 2. there is no way to really reset the fuse since it is really blown. The only way to access and reprogram flash on a cpu with blown fuse is to use the bootstrap loader if available. In some devices the BSL is omitted for security reasons as far as I know.

That is true for 1xx, 2xx, and 4xx. For 5xx and 6xx, the "Fuse" is implemented in Flash memory. They can be "blown" and "un-blown" -- if you can write and erase that Flash. Those Flash locations are usually protected and chances that you accidentally blown the fuse is very small. The tool chains for MSP430 are very poor. They often mistakenly tell you that the fuse is blown (or other kinds of mis-information). You just have to tolerate them.

Hi Jan,

I agree with OCY.  The fuses are probably not actually "blown", or, in the case of 5xx, JTAG access has probably not actually been disabled.

In reality, your startup code probably does something ill-advised (induces a BOR for example) and prevents proper JTAG entry.  If you post your code that runs first maybe somebody will pick up on something.  Your "runs-first" code is typically in main() but it might also be in the reset handler if you wrote it yourself or in a low-level init function called by your tools' reset handler / cstartup.

Jeff

Hi,

indeed and maybe I have been unclear. Even if 5xx and 6xx devices do not use a physical fuse - if it is programmed JTAG and SBW are disabled almost completely (if I remember right bypassing still works). To "unblow" access through a bootstrap loader is necessary and it's to check if it is possible.

But I agree with you that it's more likely that something prevents proper JTAG entry. 

Oops, sorry Jan.  I meant to address my reply to the original poster, Derek.

Derek, if you can post your "runs first" code, it might help.

Jeff

Hi I'm the originator of the question posted to Derek.

In response to its something in my code or startup code, the code was never running.  The problem happens when the code is being loaded by the emulator into the target.  When I power down, disconnect the emulator and re-power the target nothing runs, indicating to me at least that either the total erase worked and nothing was loaded, there was an incomplete load due to the fuses disabling the JTAG or junk was loaded until the load was interrupted by the disabled JTAG.  Again my code was never running. 

But all this aside,  the more important question is; how do I clear the fuses?  As was put in one of the above posts, the tools are poor and I just put up with it (a pretty poor situation) but I can't put up with replacing the cpu all the time.  I replaced 9 cpu's yesterday trying various methods to prevent the emulator crash with no results.  I can get one or two loads in without problems then I get a load that sets the fuse.  This should be a priority with TI to come up with a method with the existing tools to clear the fuse.  Previous MSP430's and DSP's used before erased the Flash when clearing the fuse, TI should re-tool the device(s) to do the same instead the dead-end way it works now. 

I have a deadline in two weeks, the code is unfinished (yes I know) and I can't get anywhere with the TI product or TI technical help.  If it wasn't so late in the project I would change to Microchip.  The next project I was going to use the MSP430F5418A presently used (definitely not now) or one of the TI M3 ARM processors but I seriously have to question that decision.

Todd

Hi Todd,

Just bear with me a second while I assume you are in the 99% case.  Please keep in mind that you are almost certainly the 99% case!

The tool is giving you the wrong error message. 

The fuse isn't really blown.  JTAG access is still enabled.  Just loading the code will not blow the fuse.

A "partial" load of the firmware is possible if you have a marginal JTAG connection.  Turn on the "verify" option in your tool, and review your JTAG hardware, connections, wiring, etc. 

With a partial load of your firmware, or with a firmware bug, the result could be the same.  The tool isn't able to get JTAG access again because the firmware starts executing while the tool negotiates the connection, and the firmware does something to interfere with the negotiation.

Todd Hull said:

Again my code was never running.

How can you know that without the emulator attached?  Does your startup firmware toggle a pin or something?

Do you have a custom reset handler?  Do you have a custom low-level start-up routine?  Can you post your code that runs first.

Todd Hull said:

how do I clear the fuses?

Again, the JTAG lock-out is not actually set, but to answer your question anyway, you can clear it with the TI BSL and some custom code.  Use the BSL to load some custom code that erases the final longword of the TI BSL area (or writes 0x00000000 to it).

However, my guess is that you can recover the chip just by doing a BSL mass erase.  That would prove that the firmware is interfering with the tool starting JTAG access, and that the fuse was never blown in the first place.

Jeff

Todd,

1. When you first power the FET tool do the LEDs blink and if so what is the pattern that you see?

If you are using the latest MSP430.DLL the you should see only the Green Power LED come on and the emulator should enumerate as a CDC device (under Ports in Device Manager if you are using Windows).

If you are using the old MSP430.DLL, you should see Red-Red-Red-Green followed by the green remaining lit and the emulator will enumerate as a VCP device.

If you observe anything different a firmware upgrade might resolve the issue or there might be a hardware problem.

Upgrade: http://processors.wiki.ti.com/index.php/MSP_Debug_Stack#Upgrade_process_to_MSP430.DLLv3

Note: You might have to run through the upgrade process twice, if the issue still remains.

    2.  Have you attempted powering and using the FET on a different computer?

There could be a driver conflict on the first PC.

    3.  Have you tried at all to program a TI target board, assuming that since you are so far into your development that you are working with a custom board?

    4.  Have you tried creating a new CCS workspace and loading a TI MSP430 code example?

MSP430F543xA, MSP430F541xA Code Examples (Rev. A): http://www.ti.com/litv/zip/slac375a 

    5.  If this is indeed a custom board do the JTAG connections differ in any way from the recommended connections in the MSP430 HW Tools User's Guide?

MSP430 HW Tools User's Guide: http://www.ti.com/litv/pdf/slau278h 

    6.  Does the device properly enumerate in Device manager or do you see a yellow bang beside the device in device manager?

    7.  Also, what is the exact version of CCS that you are using?

If this does end up being a tools issue, then I will need to communicate this back to the CCS Applications team.

Jeff,

The error occurs during the load and I am not using a custom startup just TI's.  The load give an error writing to memory and trying again the fuse set error occurs.  I'm pretty sure my code hasn't since I never started it.

Todd

Todd Hull said:

The load give an error writing to memory

That's the problem you have to fix.

The JTAG connection is faulty.

Once you solve that problem, the MSP430 won't be left with incomplete/garbled firmware, which means it won't interfere with JTAG entry anymore.

All of Austin's suggestions can help you isolate the problem.  The issue is either on your custom board, the cabling/connectors, the emulator tool, or the PC.  Divide and conquer.

Jeff

Todd Hull said:

In response to its something in my code or startup code, the code was never running. 

Well, the code starts running as soon as the JTAG releases the MSP. It does nto mean that it was actually doing something you expect :)

The problem with JTAG is that it is slow. When the debugger attaches to tehMSP, it can only do so after the MSP has been released from reset. Adn as soon as it is release from reset, the MSP starts executing its code.
Not JTAg tries to establish a connectionw ith the MSP and halt it. If for some reason the (already running) code on the MSP causes a device reset, or enters lowe power mode, this will interrupt the JTAG attachment and the FET will report a blown fuse. Unfortunately this is a repeated process.
A typical example is a short program that only contains the line
WDTCTL = WDTHOLD;
Since the WD password is missing, this causes a reset. And this happens faster than JTAG can attach, because there are no global variables to initialize or such.
The problem increases because the commands from debugger over USB have a relatively long latency time. (the old parallel port FETs were less prone to this problem).
The relatively slow Eclipse UI of CCS doesn't help too.

Even more, the unexpected reset of the MSP when the debugger tries to attach, might be the reason for the crash too.

Sometimes such an MSP does respond to erase attempts by the Elprotronic FET-Pro 430 lite flashing software (free), as it ha sa little lower reaction times than CCS.

If not, the only way to revive such an MSP (besides a special hardware that keeps the MSP in reset until JTAG communications starts) is to use the bootstrap loader. The BSL is triggered by resetting the MSP and if the entry sequence is properly done, it is executed before calling the reset vector and therefore before the software can cause a reset again.
And it can erase the user flash.

maybe it is possible to jsut provide the BSL entry sequence and then thr MSP might be accessed with JTAG without actually using the BSL. But I fear, the attempt to attach JTAG then will also cause a new reset and void the effort for entering BSL :)
Maybe a small logic that generates a BSL entry sequence instead of reset, and then blocks the reset signal from the FET.

Or maybe an emergency mode added to the FET firmware, to trigger a 'revive the MSP by entering BSl and then attaching JTAG and do a mass erase' operation. A job for the TI engineers ...

Hi Todd,

this seems to be some kind of communication problem indeed with your JTAG connection. Apart from updating and/or verifying the FET drivers and DLL versions, can you post a picture of your board while attached to the FET and the schematics and layout?

Very simple issues (but hard to find some times) are 

- broken / cold solder joints and the connector or any part

- conductive dirt on pins or traces

- maybe in conjuction with flux debris

- broken cables

- too long cables

For your "menace" (just joking!) to switch to microchip because of this issue - the same pitfalls are there. Indeed I personally had much more problems with PICs in the past then I had with MSPs. 

Apart from that, if there is really a problem try contacting a sales representative - at least here in germany they are really helpful and can give you contacts to some experts.

Wish you good luck in your project and in finding your issue :-)

Jan Kesten said:

ndeed I personally had much more problems with PICs in the past then I had with MSPs.