• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 421 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.

MSP430G2403: How to check the fuse is formally blown with LaunchPad?

Stephane TOUVET
Prodigy 20 points
Part Number: MSP430G2403
Other Parts Discussed in Thread: SEGGER, MSPDS, MSP-FLASHER

Hi support,

I am working on MSP430 G2 family, and I would like to check formally if the fuse is blown. I have only the LaunchPad programmer board, but with this board, and the TI win32 application MSP430Flasher.exe, there is no formal check to distinguish whether the fuse is really blown or the hardware setting is not correct. It gives basically the same error. Deeper verification can be done on some hardware as Replicator with function IsFuseBlown() but this seems to be not supported by LaunchPad embedded firmware.

IsFuseBlown()verify that TDI signal is returned on TDO delayed by one TCK pulse, and so giving high confidence that fuse is really blown and MCI is not out of order or hardware setup is incorrect for this verification. I precise that the MSP430 target is already on PCB and I cannot rely on operation done before.

Do you have any easy suggestion to perform this test as straightforward as possible? Due to Covid-19 situation, it will be very difficult for me to get any other hardware.

What can I do with LaunchPad board, any basic electronic circuit or eventually with a Segger J-Link probe (Segger software seems to not support MSP430). I would like to reuse also any part of software as if I need to redevelop an embedded software, I can figure all the workload as I fully read the SLAU320 document and have a look on source code for Replicator!

Any suggestion will be greatly appreciated!

Thanks and best regards,

Bob

  • 0
    Guru 33653 points

    LP can not blow G2xx fuse (there is no 6.5 VPP generated on LP board), so G2xx device that is been used only with LP is 100% with unblown fuse.

    Even if you made minimum Replicator like setup, fuse blown function can have wrong result. This can be due to bad firmware flashed, that lead device in some wired state, that can be back to life only by forced mass erase (ignoring fuse blow and all other SBW / JTAG errors).

    If G2xx device is with BSL, than BSL can help too, but with previously saved calibrated data from info segment A.

    You can check existing function list from open source 430 ddl that is used by FET's  form MSPDS, and than add call of fuse related function (if exist) to open source MSP-Flasher.

  • 0 in reply to zrno soli
    Prodigy 20 points

    Thank a lot for your quick answer.

    Clear, as LaunchPad does not implement Vpp, it cannot blown fuse, so it makes no sense to check it state!

    Your second point is quite interesting in my situation. I thought that if you perform the right sequence for JTAG fuse check after power up, as explains in slau320 (Chapter 2.3.1.2 - Fuse Check and Reset of the JTAG State Machine (TAP Controller)), this is the only condition so that the JTAG State Machine reflects the fuse state. Why some content of Flash memory can interact with fuse state (this is a poly fuse for MSP430G2 series not a bit in Flash)? So my understanding is with some corrupted data in Flash, it can cause exactly same situation as an incorrect fuse check sequence a power up, before executing IsFuseBlown() method. What is the explanation of this JTAG behavior?

    As also explained in slau320 document, it seems that a current of up to 2mA flows the Test pin and fuse while it is checked. Could it be another more reliable method for checking if fuse is blown by measuring the current on Test pin when fuse check is performed (by an appropriate setup with scope)? Or does the Flash corruption will also not let to check the fuse, so preventing to have this current on Test pin and so will be not better than the result given by IsFuseBlown() method? I can imagine that a transistor switch the fuse to Test pin when fuse check.

    About the last point, you suggest to use fuse related function. But with LP, as it will not support IsFuseBlown() primitive, so event if I call a relative API in MSP-Flasher, at best it will do nothing? What are you suggesting exactly?

    Thanks and best regards.

  • 0 in reply to Stephane TOUVET
    Guru 33653 points

    No, now I am not 100% sure (actually, don't remember) if I had wrong fuse check report for 2xx flash family, but I am sure that I have it  for 5xx flash family (because I use it more frequently). There is no VPP and poly fuse with 5xx, but due to wrong firmware SBW / JTAG was locked (with reported fuse blow) even BSL flash segments (where fuse value is stored) were locked / untouched / not modified. Some devices are back to life by leaving them unpowered on side by few hours. Others only by forcing SBW / JTAG mass erase (with ignored errors).

    D:\>flash -forced -e

Found master device at COM4

Get Device
# JTID Fuse
0  91 Blown
Error 101: ...

Erase
Error 107: ...

Release Device

D:\>flash -forced -e

Found master device at COM4

Get Device
# JTID Fuse
0  91 Blown
Error 101: ...

Erase
Error 107: ...

Release Device

...

D:\>flash -forced -e

Found master device at COM4

Get Device
# JTID Fuse Device Core Hard Soft LotWafer DieX DieY
0  91   OK   3180  1104  12   12  013BB046 0D00 1E00

Erase
Time: 37 ms

Release Device

    SBW entry sequence is equal for MSP430 devices (all families), so one used by FET or LP is similar to slau320. And fuse check is part of SBW entry sequence, and it is used in all SBW master devices.

**Attention** This is a public forum