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.

Differences between MSP-FET430UIF programmer and MSP Gang Programmer

Other Parts Discussed in Thread: MSP430F5151, MSP-GANG, MSP-FET

Hi everyone,

I'm programming a lot of boards which contains the MSP430F5151 device and happens that, some time, the programming sequence fails.

When i try to connect again the MSP-FET430UIF programmer to the failed board, the connection fails during the GetCoreId and I'm not able to erase the device.

The MSP gang programmer can recover the device successfully and erase the device.
After this, i can use again the MSP-FET430UIF.

What is the difference between this two programmers?
Why one programmer can recover the device and the other one can't?

Thanks in advance,

Fabio Rocca

  • Fabio Rocca said:
    What is the difference between this two programmers?

    FED programmers are not only programmers but also in-circuit debuggers. Gang programmers are just programmers for (mostly) manufacturing purposes.

    Fabio Rocca said:
    Why one programmer can recover the device and the other one can't?

    Usually different (programming/reset) speed is source of differences, other issue could be EMI, especially if using FET you power device from different (to computer) power supply. Try to prolong time of the reset, set slower programming clock, make sure programming cable is low capacitance, check and fix grounding issues of your programming setup.

  • Fabio Rocca said:

    What is the difference between this two programmers?

    Why one programmer can recover the device and the other one can't?

    If I remember right FET430UIF was about 100$, and MSP-GANG is 250$.

  • Thanks for support,

    I need to know why the Gang programmer can unlock (or recover) the device. Do you know it?
    Maybe it is because it has 2 more signals or it have some special sequence?

    Thanks,
  • Fabio Rocca said:
    I need to know why the Gang programmer can unlock (or recover) the device. Do you know it?

    In my opinion I already told you:

    Ilmars said:
    Usually different (programming/reset) speed is source of differences, other issue could be EMI, especially if using FET you power device from different (to computer) power supply. Try to prolong time of the reset, set slower programming clock, make sure programming cable is low capacitance, check and fix grounding issues of your programming setup.

    Fabio Rocca said:
    Maybe it is because it has 2 more signals or it have some special sequence?

    Which 2 signals you talk about?

  • Fabio Rocca said:

    I need to know why the Gang programmer can unlock (or recover) the device. Do you know it?
    Maybe it is because it has 2 more signals or it have some special sequence?

    While FET430UIF is open software / hardware, MSP-Gang is not, so nobody can give you precise and correct answer. Both are working with same SBW / JTAG standard (I guess with same DLL from PC side). There is no 2 more SBW / JTAG related signals.

    You can compare complete SBW / JTAG sequence for both by scope, but even this is not enough for clearing all doubts.

  • Hi Fabio,

    I agree with and that the main difference in the behavior you are seeing is likely the timing of the MSP-GANG related to the MSP-FET430UIF. The MSP-GANG can program more quickly than the MSP-FET430UIF, and it only has to program the part not setup debug - the JTAG startup/initialization is going to have a different timing than the FET. I've run into the same issue myself before - typically what was happening when I could get in with the MSP-GANG but not the FET was that bad code had been loaded causing the part to reset (e.g. WDT ran out before getting to main due to large number of variables). In these types of cases the timing of trying to get control of the device in relation to when your bad code causes the reset, it going to matter for whether you can get into the part or not, and that's why the one tool worked and the other didn't. After erasing the part both tools work fine again.

    Regards,
    Katie
  • I notice that in the schematics there are 2 singals respect the MSP-FET: BSL_TX and BSL_TX.

    Maybe our costumer uses this to recover the board?

  • Fabio Rocca said:

    I notice that in the schematics there are 2 singals respect the MSP-FET: BSL_TX and BSL_TX.

    Maybe our costumer uses this to recover the board?

    Could be so. - But only in case if they wired BootStrapLoader UART TX & RX pins into programming header. Do you have schematics of user device to verify?

  • Our costumer uses this signals and the MSP-FET dosen't support them.

    Can someone tell me that this is the way to recover the boards using this 2 signals?

  • Fabio Rocca said:
    Can someone tell me that this is the way to recover the boards using this 2 signals?

    Yes, this is the way, but not only one. Design shall not lock-out JTAG of msp430. You shall be fixing cause, not consequences.  As Katie already pointed out - firmware could be the cause of problems, also incompatible reset circuit could be one that leads to JTAG errors. As you are not providing more information for analysis - nobody can tell more than educated guesswork.

    Further reading about BSL: SLAU319, adapter.

  • Fabio,

    I think you are asking if the customer can use the BSL to erase the MSP so that you can get rid of any bad code that's causing the issue - then you could regain access via JTAG on the FET tool. This is true you could do this (both MSP-FET and MSP-GANG support UART BSL if you wire up the correct connections) - but since you already seem to be able to get access via JTAG on the MSP-GANG, that would be an easier way to erase the bad code from the device.

    Using the MSP-GANG GUI, simply click "Erase" (instead of GO which will carry out the whole programming process) - this should let you erase the part without re-programming it. You may want to run "Blank check" afterwards as well to make sure you erased all the code. Now with a blank part, see if you can get back into the device using the MSP-FET instead. But I'd recommend loading known good code this time (use one of the device basic code examples maybe). If you load the same code you had before, you'll just have the same problem again if it turns out to be the code that is your issue. If erasing the part lets you get back in via MSP-FET, that means it's almost certainly the code that was causing the problem - and as Ilmars mentions above, you need to figure out the root cause - what part of your code causes the problem. One common reason this might happen is discussed in this other post: e2e.ti.com/.../778687


    However you could have something else causing the problem as well - you might have to start commenting things out until you see that it stops having the issue, to narrow down the part of your code that is responsible. Or you can see if the part is resetting by toggling a pin briefly at the start of your code - if it does this multiple times you know the part reset. If the part is resetting, then you can start reading out SYSRSTIV to see if it can provide a clue as to the reset source (WDT reset, SVS reset, etc).

    Regards,
    Katie

**Attention** This is a public forum