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.

MSP430F5151 flash programming SBW issue

Other Parts Discussed in Thread: MSP430F5151

Hi all,

I'm working on my application that involves the On Board Programming of the MSP430F5151 device.

I'm developing a driver for a costumer using the SBW interface (2 wire JTAG).

I followed the SLAU320m application note (pdf document and source code) and I used our hardware instead of the Replicator430Xv2 board as we had already done for other MSP devices.

We program and verify correctly 16 device, but I cannot access anymore to half of this device.

If I program a PASS board 100 times, it always pass; while a FAIL board it blocks itself after the first erase/write/verify cicle.

The code stucks in the GetCoreipIdXv2 function

  • With a working board I receive 0x01A00 from the device
  • With a fail board I receive 0xFFFF

The fuses aren't blown and I can correctly start the communication with JTAG port.

I tried to connect the device with officials programmers:

  • MSP430 USB debugger doesn't connect anymore with the fail boards
  • Gang-Programmer, which our costumer use, can re-program the device.

What could be the problem?

Why some device work and other don't?

Thank in advance 

Fabio Rocca

  • I had such a problem, too. Almost 20% of our delivered boards weren't programmable and we sent them back. After some research we found out that our MSPFET (the older grey one) was the problem. After replacing it all boards worked fine.

  • The problem is that i'm attempting to program the device with our custom programmer.
    I copied the sequence from the source code and SLAU320m application note, but i still have this problem.
  • If today, because of some reason, I need to build my custom SBW programer based on TI open software/hardware, for sure will use as base or copy new eZ-FET (slac460 Open Source MSP430.DLL ), and not slau320 Replicator.

    And don't understand why for customer you are building SBW for flash updates, when it is much easier and more safe to use BSL for this.

    As starting point for my SBW+ programmer I use slau320, because at that time noting else was available. 

    But at the end it is gone to completely different direction.

    Your problem is related to entry sequence, part before shifting out Core ID, so you can analyze code from last correctly shifted out value, JTAG ID / Fuses.

  • Thanks for your support,

    We are developing the SBW driver because, when we started to make MSP430 drivers, the BSL wasn't explained with a documentation.

    With failed boards, the JTAG ID and fuses are correctly received, but the CoreID is 0xFFFF.

    I really don't know why.

    Thanks again,
  • Debug until you reach the point where shifting results are OK. Shifting result 0xFFFF for Core ID (or anything else) mean that problem appear before that shifting. Also, my programer use Core ID only for presentation, and it is not requested, so you can try comment this shifting, and I believe that shifting after will give you same result (0xFFFF).

  • Already tried. If I comment the CoreId Check, it gives me the same result 0xFFF.
    I think that the communication between the SBW port and the Core has some problem.
  • There is some problem with entry sequence. Maybe you can try older (less complicated) slau320 revisions. And what about other 5xx devices. This MSP430F5151 is first 5xx sample that you working on, and till now your programer was handling only 2xx targets? Try to do mass erase on problematic targets using other (not your) programmer, and than try to connect with your programmer to erased / blank device.

  • As written in the first post:

    I tried to connect the device with officials programmers:

    • MSP430 USB debugger doesn't connect anymore with the fail boards
    • Gang-Programmer, which our costumer use, can re-program the device.

    I'll ask to the costumer to erase it with the Gang-Programmer and re-write them with our driver, and see if the problem persist, but I think this is not the best solution.

    Thanks for your support

**Attention** This is a public forum