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.

MSP430F5528: JTAG programming problems

Part Number: MSP430F5528
Other Parts Discussed in Thread: MSP-FET


I'm updating MSP430F5528 firmware in our project using the JTAG port, which is controlled by a master processor, per SLAU320T (4 wire JTAG).
I ported the project code to a non TI processor, and it works, usually...

We have seen a few cases where the update fails (explained below), and once it does, it will not program again unless
I connect the MSP430 USB Debug-Interface to the JTAG header, and use the FET-Pro430 software from Elprotronic.
I found, I don't even need to erase and program the device, but just by doing a memory Read from Elprotronic seems to be enough to "fix" whatever problem the MSP430 has.
I can then remove the programmer, power up my device as normal, and program through my JTAG interface like nothing happened.

Not sure of the reason for the occasional failures, but I can duplicate the problem if I unplug the device before programming has completed.

I found the failure is in the GetDevice_430Xv2() routine.

This section is returning an error:

if (IsLockKeyProgrammed() == STATUS_OK) // Stop here if fuse is already blown
{
return(STATUS_FUSEBLOWN);
}

From the comment in code, it seems the fuse is blown, yet it's probably not really the fuse, but a JTAG communicatons problem.


I've lowered the RST pin capacitance to 2.2nF (it was 100nF) and added a 47K pullup, though the MSP430F5528 has an internal pullup. Still no luck
I've tried forcing the MSP into BSL mode on power up by pulling PUR up to 3.3V through a 100 ohm resistor in order to prevent possible bad code from executing.
- Even though USB is not used on this device, as suggested here:
e2e.ti.com/.../1006192

I'm now at a point where I'm trying to capture the JTAG signals on a scope, to try and figure out what Elprotronic might be doing different to make this work, but it's not the
easiet thing to figure out.


Any help would be appreciated.

  • Hello Andy,

    Are you trying to do an embedded JTAG programming from a host MCU here? If so, have you seen the Replicator Code that does this? (www.ti.com/.../rep430f)
    The above link is the best resource for if you want to continue down this path. Also, for HW connection recommendations, please see Figure 2- 1 within the MSP Hw User Guide (www.ti.com/.../slay278).

    Pulling the PUR line up is only for engaging the BSL. It you are doing JTAG connections, it is not recommended to do this. that being said, the BSL was developed in order to reduce resources within an embedded system in order to initially program, or upgrade FW to the MSP430 device. It is true that the MSP430F5528 comes with a USB interfaced BSL. You have stated that you do not use the USB connections. You can replace the USB BSL with a UART version in order to change the BSL interface. This would make your program to update the MSP430 FW on your Host smaller and easier to implement as its just the BSL protocol over UART. We do provide an example of UART based BSL for this device within the Custom BSL documentation. (www.ti.com/.../slaa450).

    If you are not doing JTAG within embedded system and are using the traditional MSP-FET debugger, then please make sure of the following. Ensure HW connections are what is pointed out in the linked MSP HW User Guide above. Ensure total trace length from debugger to MSP is shorter than specified amount in MSP Debuggers User Guide for the debugger you are using. (http://www.ti.com/lit/slau647). I believe the distance is 6cm, but please check the document for exact size. The ribbon cable provided with the debugger is short enough as long as you do not add additional sky wires to a board or have excessive capacitance. Also ensure that the board is powered properly before trying to use JTAG. If the debugger is providing power, please ensure you do not exceed the max current the debugger can provide, as that will "brown-out" the debugger and cause communication problems as well.
  • Hi Jace,

    Yes, I'm trying to do embedded JTAG programming from a host MCU, and I'm using the code from the Replicator project.

    I checked the length spec in the link provided, and it lists the JTAG cable length as 20cm max. Our PCB is much smaller than this so I don't think we are violating the trace length.

    I understand that we don't need BSL mode, but the idea was that something, possibly partial code that was not erased, was interfering with the JTAG connection process, and by putting the MSP in bootloader mode right at power up, it might be in a stable state so as not to interfere with the JTAG connection. It didn't  make any difference.

    The question is, why does the MSP-FET Debug/Programmer always work (and going through ~ 1 foot JTAG cable), and my JTAG drive with a relatively short signal path not work, in the situation where I previously interrupted the programming process? It doesn't seem that I should need to develop a UART based BSL.

     Maybe our drive is too weak, even with short traces?

    There is a suggestion from TI to pull down the TEST signal with a 4.7K resistor. could this help with the other JTAG lines?

  • Hello Andy,

    You are correct in saying that you do not need a BSL implementation. I'm just pointing out that it is a simpler and easier solution than doing Replicator Code on a host device. It is also the recommended path.

    The 4.7k pull-down resistor on TEST is specific to some FRAM devices that show some sensitivity on the TEST pin. It is not recommended for this device.

    It could be possibly by drive strength, but more than likely it is timing of the signals.
  • Hello Andy,

    Where you able to resolve your issue? If no response, i will be closing this thread soon.

**Attention** This is a public forum