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.

REP430F SBW connection to MSP430G2211 is confusing to me

Other Parts Discussed in Thread: MSP430G2211, MSP-GANG, MSP430F2001, MSP430F1101, MSP-TS430PW14

I would like to use the software described in SLAU320C and SBW  connection to an MSP430G2211but I am confused about the connection and software.  The software function StartJtag clears and then sets the target JTAG TEST signal, then runs an initiation sequence using SPWTDIO and SBWTCK.  But on the MSP430G2211, TEST and SBWTCK are the same pin.  Do I in effect OR these two signals out of the REP430F, do I leave TEST unconnected, or what?

  • Ok, I'm trying to set up JTAG communication with an MSP430G from another one.  I've tried both SBW and 4-wire mode.  I'm using the code from SLAU320C and have verified signals with a logic anaylzer.   I am not getting anything back on TDO, which leads me to suspect that I have something wrong in the fuse check routine.  I've been working on this for hours and can't seem to find my problem.  Any help or pointers would be appreciated.

  • Hi,

    Are you using the Elprotronic REP430F hardware? They have a schematic of this in SLAU320. The JTAG connections for the REP430F using SBW should be the same as if you were connecting our MSP-FET430UIF tool using SBW, so my best advice would be to see the Hardware Tool's User's Guide figure 2-2 Signal connection for 2-wire JTAG (p. 26). So you're going to connect JTAG pins from the REP430F to your target board as shown in that picture (the pin numbering in Figure2-2 for the JTAG header matches the pin numbering in the REP430F JTAG header schematic). Make sure to include the required pull-up resistor and pull-down cap on the RST line following the values shown in Figure2-2, or you'll have problems.

    I don't know 100% if the REP430F software supports all of the G2xx parts at the moment, but at least this will get you the correct hardware connections. Let me know how this goes.

    Regards,

    Katie

  • Katie Enderle said:
    Are you using the Elprotronic REP430F hardware?

     Hi Katie, from original post I understand it was trying to program a G series from another G series:

    "Ok, I'm trying to set up JTAG communication with an MSP430G from another one"

     More detail of what intend to do and what is wrong needed to.

     Regards

  • Thanks for the replies.

    My primary goal is to be able to blow and check the security fuse.  I don't need all of the complexity of the Replicator nor all of the software in the package. I am not using the Replicator hardware, but a much-simplified version.  For example, I don't need the signal-level translators, pushbuttons, and LEDs.  I am using a G as the host and as the target.    The connections from host to target are direct connections from the GPIO port pins of the host to the JTAG pins on the target.  I have adhered to the -RST pullup and capacitance restrictions.  

    I have of course had to modify the software by reassigning port pins to my host processor, and eliminate code that I don't need.   I acknowledge that I may have made errors in doing so.  Frankly, the application note and code package is at times confusing.  For example, there are multiple code versions in folders labeled Replicator, ReplicatorX, and ReplicatorXv2, and they have differences.  For example, in one version the code to toggle TMS as part of the ResetTAP routine has been removed, with a comment that it is not needed for 5XX parts, but it appears to have been removed completely.  So I have tried it both ways. Also, the low-level timing of protocol has been changed, and I have tried variations of that as well.

    My basic issue is that I am attempting to use this application note and code to establish a host-to-target JTAG and/or Spy Bi-Wire communication with a target G2211 and I have been unsuccessful.   The target never responds with TDO data, so I suspect that it is behaving as if the fuse check protocol as described in 1.3.1.2 of the application note has not been performed.  I have tried both the Spy Bi-Wire and 4-wire JTAG sequences.  I have verified the host code by watching output signals on a logic analyzer and compared with timing diagrams , for example Figure 1-11 JTAG Access Entry Sequences in my attempt to use 4-wire JTAG mode, and I appear to be in compliance.  But I suspect I am off with something, as I am unable to get the target to send back the 8-bit ID when I send the first 8-bit Bypass command that the software package uses.  So I am looking for any suggestions or debug approaches at this point as i seem to have exhausted my own.

    My logic analyzer is not sophisticated, so one thing that might help would be a signal trace of a successful opening Spy Bi-Wire or 4-0wire JTAG of a Replicator to a G or protocol-compatible device.  from that I could perhaps determine what I am doing wrong. 

  • Hi,

    Is there a reason for not simply using a programmer like the MSP-FET430UIF or MSP-GANG (for production)? In my experience, using the replicator code is one of the most complicated and difficult ways to program/verify/secure a part, and there are usually easier ways of automating and customizing your programming flow by using the something like the MSP430.dll/GANG430.dll or debug server scripting. Particularly if you are doing any sort of mass production by this process I'd highly recommend one of these other options.

    For using the replicator code: The reason there are multiple code versions are for the different types of devices we have and their different JTAG/debugging features. You need to determine the correct code version to use with the device you are trying to program, in this case a G2xx part. You can find this in table 1-14 of SLAU320 - see the CPUX column of the table and you'll see that for the G2xx this is listed as "false." That means that you should be working off of the code in the Replicator folder - ReplicatorX would be for devices with CPUX = true in the table, and ReplicatorXv2 is for devices listed in table 1-15 (5xx, 6xx, and FR5xx). I would also double check all of your connections against the Hardware Tool's User's guide Figure 2-2 as the pin connections for SBW are different than those for normal 4-wire JTAG.

    Regards,

    Katie

  • Katie,

    Thanks for your reply.  I missed the meaning of CPUX in the table so thanks for pointing that out.  I started out with code from the Replicator folder, but I will go back and double-check my code against that folder, as i tried some variations.  Thanks also for pointing out the connections in the Hardware Tool's user's Guide; I had looked at those for reference.

    Using one of the TI tools that you mentioned is an option and in fact I have an MSP-FET430UIF on its way.  My understanding is that it can blow the fuse in 4-wire mode but not Spy Bi-Wire mode, and I prefer the simplicity of the two-wire connection.  I have read some postings that say it can't be done, but the application note Figure 1-16 shows a SBW timing diagram for doing this which I assume can be done on a G part.  But I am able to use a 4-wire connection if necessary.

    Getting info like this from a TI employee in a timely fashion is much appreciated.

    Dick

  • Hi Dick,

    You can blow the JTAG fuse in either SBW mode or 4-wire JTAG mode with the MSP-FET430UIF. The confusion may arise from the Launchpad (which uses SBW) being unable to blow the fuse, but this is rather due to the emulation section of the launchpad not having the correct hardware to implement fuse-blowing functionality, since it is meant as an evaluation programmer rather than one for production like the MSP-FET430UIF.

    The important thing to remember when using your FET tool in SBW mode to blow the fuse is to make sure you have resistor R2 from the diagram below in place and make the additional connection from TEST/VPP to TEST/SBWTCK (this connection is not made unless fuse blowing is required). The resistor R2 protects the JTAG TCK line from the fuse blowing voltage applied on the line.

    Regards,

    Katie

  • Prefect!  Thanks again!

    Dick

  • Katie Enderle said:
    JTAG TCK line from the fuse blowing voltage applied on the line

     Hi Kaie, I also posted this to Jason, why not include an 1K resistor between R1 C1 Node and JTAG<->MSP RST/SBWTDIO line? This can isolate UIF driver from 2n2F capacitor and save a lot of troubles.

     Again I use Olmex ISO and UIF standard was broken in a good way but this is different from UIF pinout and work without swap, why swapping pin behavior and not try to drive lines as Olimex do and Eprotronic Flashpro can do as option?

     Regards

     Roberto

  • Dick Bipes said:

    My primary goal is to be able to blow and check the security fuse.  I don't need all of the complexity of the Replicator nor all of the software in the package. I am not using the Replicator hardware, but a much-simplified version.  For example, I don't need the signal-level translators, pushbuttons, and LEDs.  I am using a G as the host and as the target.    The connections from host to target are direct connections from the GPIO port pins of the host to the JTAG pins on the target.  I have adhered to the -RST pullup and capacitance restrictions.  

     Hi Dick, if you just need blow fuse replicator code is far away what is needed to blow and check the fuse, I remember my fuse check and programmer was based an a mere MSP430F1101, code generate the pulse sequence to check if fuse blow and lit an LED, otherwise if button pressed then generate high voltage from a capacitive booster then generate the 1mS blow pulse required. Nowadays a simple MSP430F2001 two led a couple of mosfet can do the job from 2/3 AA cell battery.

     Regards

  • Roberto,

    I'm with you; I just seem unable to get JTAG communication established having modified the Replicator code.  If you have simpler code that you would be willing to share, I would appreciate it. 

  • Some progress, but not there yet.

    I got an MSP-FET430UIF and wired up a target board per Katie's schematic.  It is basically the same thing as the MSP-TS430PW14, except that I am using 14-pin DIP parts and socket.  I also have an LED and resistor connected to P1.0 like that board, so I can run code to toggle the LED and visually verify that it is running.  With this setup I can successfully connect, download code, run it, set breakpoints, etc. But (using CCS 5) when I click on Run - Advanced - Make Device Secure, I get the following:

    MSP430: Trouble making device secure: Could not blow device security fuse

    GEL_SecureDevice() cannot be evaluated.

    Could not secure the device

    I have tried both 2-wire Spy Bi-Wire mode and 4-wire JTAG mode with the same results (currently set up for the latter).

  • Follow up:

    I scoped the target while trying to blow the fuse, and I could not find sufficient voltage present at TEST to blow the fuse.   I opened up the FET and looked at the fuse programming (blow) voltage, triggering on the enable signal to the solid state relay for applying the voltage.  The voltage is never more than about 3.3 volts, and it rises only marginally on an attempted fuse blow event, but the MSP430G2211 spec sheet says it musty be 5-6 volts.  So I don't think that the FET firmware is generating the correct voltage to blow the fuse.  Is there a place to set this?  I would think that by specifying the target part number it would be properly set.  I'm using CCS 5.

  • Dick Bipes said:
    and it rises only marginally on an attempted fuse blow event, but the MSP430G2211 spec sheet says it musty be 5-6 volts.  So I don't think that the FET firmware is generating the correct voltage to blow the fuse.  Is there a place to set this?  I would think that by specifying the target part number it would be

     Hi Dick, I hope UIF has trouble, check the DC-DC step up converter built around a mosfet and inductor to generate programming voltage.

     For simple Fuse programmer I searched thru my library but I cannot find it, on new datasheet there is no more programming and test sequence.

     regards

    Roberto

  • Yes, I have checked that one and it is not producing sufficient voltage from what I understand.  Since it is run off a port on the FET's microcontroller and it looks like the voltage is controlled by the switching frequency I am guessing that it may be a FET firmware or software issue.  I could check the switching frequency but I have no reference.

  • Hi all,

    I have reproduced Dick's issue (unable to blow fuse in CCSv5) on another MSP430 device. We are currently investigating this issue and I will post back when we know more.

    In the meantime, I have found that an older version of the MSP430Flasher software does not exhibit this issue, so I'd recommend this as a pretty simple way to blow your fuse in the meantime. Just follow these steps:

    1. Downgrade your FET tool firmware following the steps here: http://processors.wiki.ti.com/index.php/MSP_Debug_Stack#Downgrade_back_to_old_MSP430.DLLv2

    2. Download this version of the MSP430Flasher software:http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer-Discussions-Components-Files/166/3343.MSP430Flasher.zip

    3. Open a Command Prompt window and navigate to the directory where you've unzipped the MSP430Flasher folder you just downloaded.

    4. With your FET tool connected to your target board, you can blow the fuse with this command: " MSP430Flasher.exe -n MSP430G2211 -f". If it asks to update your FET firmware, say yes, then try the command again once it's done updating. (-n should be followed by the device you are trying to blow the fuse of, and -f indicates to blow the fuse. If you'd like, you could flash a code image before blowing the fuse using the Flasher software too). You can find more information on using the Flasher software on this page: http://processors.wiki.ti.com/index.php/MSP430_Flasher_-_Command_Line_Programmer

    Regards,

    Katie

     

  • Thanks Katie!  I will give that a try.

    Being impatient to get this working, I actually had just finished hacking my FET by gating an external 6V supply through a diode onto TEST in parallel with the FET, using the gate signal to the FET's solid state relay for VF, and that worked.  (It was important to me to establish a viable solution of some kind today.)  Again, thanks for your attention to this.

    Dick

  • OK, here are my results:

    I cannot access the part that I blew with my hacked FET using my external supply, either with the FET and MSP430Flasher or with CCS 5 and a LaunchPad.  

    I removed the hack and followed your instructions.  Using the FET and MSP430Flasher, I first read the memeory to a file, then flashed a new part writing that file to the new part.  I tested that part in my prototype product circuit board, and it worked as expected.  Then I put the microcontroller back on the FET and ran the command to blow the fuse.  Then I tried to read MAIN memory using MSP430Flasher, and I got an Error 16 during the "accessing" step (I expected to get some kind of error).  But, when I put that part into LaunchPad, I was able to access it with CCS and download a completely different application with no problem.  So it appears to the FET that the fuse is blown, but not to the LaunchPad.  So I'm not there yet - the part is not secure.

    BTW the FET is connected in 4-wire JTAG mode, and the LaunchPad is obviously Spi Bi-Wire if that matters.

  • Whoops!  Sorry - I must have made some error.  I tried again and it worked fine - I got a confirmation message from MSP430Flasher that the fuse was blown.  I'm using a zif socket, and I suspect that I forgot to lock it the first time.

    Sorry!

  • Hi Dick,

    Glad to hear you were able to get your security fuse to blow.

    Just to follow up: there is already a fix for this issue being implemented for the next release of CCS and IAR, which will also include a number of other fixes. In the meantime, for blowing the fuse on 1xx, 2xx or 4xx devices you'll either need to use CCSv4 or do it like you did with the older version of the Flasher that I sent you. Either of these options requires a firmware downgraded FET tool (downgrade process here: http://processors.wiki.ti.com/index.php/MSP_Debug_Stack#Downgrade_back_to_old_MSP430.DLLv2)

    As a note, 5xx and 6xx devices are not affected since they use a different security fuse mechanism.

    Regards,

    Katie

  • The Flasher utility is working well, and with a batch file is actually well-suited to my needs.

    Thanks.

    Dick

  • Dick Bipes said:
    The Flasher utility is working well, and with a batch file is actually well-suited to my needs.

     I hope you no more need my stand alone fuse checker and zapper, I am not able to find online so I hope it is on old HDD pc or server. If you need I can try redesign again and leave to public domain.

     See also this as a suggestion : RESET thread. In all my new design I add resistor in series to capacitor, I never experienced trouble on SBW debugging.

     Regards

     Roberto

  • Roberto Romano said:

    The Flasher utility is working well, and with a batch file is actually well-suited to my needs.

     I hope you no more need my stand alone fuse checker and zapper, I am not able to find online so I hope it is on old HDD pc or server. If you need I can try redesign again and leave to public domain.

     See also this as a suggestion : RESET thread. In all my new design I add resistor in series to capacitor, I never experienced trouble on SBW debugging.

     Regards

     Roberto

    [/quote]

    Thanks for the offer, but I am successfully using the FET430USB now, so I have no real need for an alternative. 

  •  Hi Dick, I have to say you sorry, a friend pointed me about sometime I use the word hope in a wrong way, rereading the post I see in this case also the first one is inappropriate.

     Please accept my apologizes about.

     Regards

     Roberto

  • Roberto,

    No problem and no apology needed.  I got your meaning.  As a person fluent in only one language, I admire those who know more than one, and would never criticize them regarding proper use of English, grammar, or spelling.   

  •  Hi Dick, thank for understanding my meanings about, please if you read something that sound offensive to point me to that so I can correct and learn also good rule of language.

     Thank you very much.

     Roberto