• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 78 subscribers
  • Views 1169 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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

Fabio Rocca
Prodigy 140 points
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

  • 0
    Guru 74080 points
    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.

    Dennis
  • 0 in reply to Dennis Eichmann
    Prodigy 140 points
    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.
  • 0 in reply to Fabio Rocca
    Guru 33653 points

    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.

    http://forum.43oh.com/topic/5530-custom-ezfet-lite

    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.

    http://forum.43oh.com/topic/2972-sbw-msp430f550x-based-programmer/page-4 

    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.

  • 0 in reply to zrno soli
    Prodigy 140 points
    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,
  • 0 in reply to Fabio Rocca
    Guru 33653 points

    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).

  • 0 in reply to zrno soli
    Prodigy 140 points
    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.
  • 0 in reply to Fabio Rocca
    Guru 33653 points

    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.

  • 0 in reply to zrno soli
    Prodigy 140 points

    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