Trouble initializing JTAG interface

Fernando,

I am very impressed with what you did. I tried to do the "2-wire " version a long time ago and did not get very far. The document I manage to find at that time was inadequate, inaccurate and very difficult for me to understand. If I remember correctly, the "bypass mode" is an indication that the fuse is blown. But I do not think you have blown the fuse (deliberately or accidentally). If you have another working JTAG tool, you can use that to check the fuse. LaunchPat is an interesting one. I ordered some three month ago from TI e-store. I am still waiting.

I am a hobbyist and understand why you took the "rocky road" – or the road less traveled. It is the journey, not the destination, that interests hobbyists.

I will try to dig out my old SBW attempt and see what I can tell you about what I learned. Can you tell me where you find the information about TI MSP430 JTAG? I only have very old information. If you want, you can e-mail me via old_cow_yellow@yahho.com

-- OCY

Hi OCY,

Very thanks for your comments, rocky road is the preferred for an hobbist . . .

I'm also having troubles with documentation available from TI. I've read appnotes and whitepapers from other hardware manufacturers using JTAG and it seems that all of them (including TI) have customized the protocol at the point of building a subset of it, hard to understand

I don´t think I've blown the fuse, because I checked all sample IC's with same result. The electrical check is always ok (toggling twice TMS), so it looks like uC is going into bypass mode by a protocol misunderstand rather than by fuse blown. Unfortunately, it seems that not much people have tried to implement the JTAG protocol by his own, since programming tools are really cheap and versatile

I've searched many days the web looking for clues, and the nearest reference I took was from a forum that stated something like "you must provide the correct signal sequence in all the pins when initializing the JTAG interface, or the MSP430 will go into bypass mode". This is not explicit in official documentation, but I think this is what happens in my case

What documents I've used? SLAU265E (latest version of programming user's guide), SLAA149 (old version prior to SBW and BSL modes, the major difference is that fuse is checked prior to resetting TAP, rather after like SLAU265 does), the C routines in LowLevelFunc.h and JTAGfunc.h (which I've ported to assembler for my prototype board), the very nice JTAG-Scan Educator program from TI, MSP430 datasheet, etc, etc, etc.

I'll keep trying variations of the entry sequence, I suspect the sucess is just a clock ago. If you found something in archives, it will be appreciated

Rgrds

Fernando

Fernando and possible others,

I did not keep very good record of my previous attempt to implement JTAG controlling of MSP430. Here is a summary of what I managed to patch together what I have done.

I started the project after I read the TI Application Note slaa149.pdf. My objective was to develop a simple and yet versatile method such that one MSP430 can have total control of another MSP430 as a port expander, an intelligent peripheral, or a slave processor. This has a number of advantages (as well as disadvantages) as compared with other more conventional interfaces.

I did not understand most part of slaa149.pdf. But part of the associated code files slaa149.zip was very helpful. Some of the operation I wanted to do were in the original c-source code but commented out. I implemented those functions in assembly code. But they did not work. I could not even grab hold of the slave MSP430 with SBW.

Next came the eZ430-F2013. I started to reverse-engineer the code in the USB part of it. That was very difficult for me too. But I managed to get through the very beginning part -- how to grab the control of the target with the SBW-interface. When I put this together with the rest of my earlier implementation of things like read target status, read/write to memory/peripheral, stop cpu, change PC, start cpu, etc., they worked! I did not try to erase/write to Flash which were the main objectives of slaa149 but only secondary to me. I assume that they would work too.

Thus I almost achieved my objective. However, I was disappointed that it was very tedious. Worst of all, I still did not understand what I was doing. I gave up and did not even archive or document.

Fernando’s posting motivated me to review my old project. I found that slaa149.pdf was later merged with BSL Programming into slau256.pdf which was later split into slau360.pdf without BSL Programming. The “commented out” c-source code which I based my attempt on was still there hiding a few layers down.

Download [slau360.zip] from TI web-site, unzip that.
Go down to [JTAG Programming]=>[slau265c.zip], and unzip that.
Go down to [SLAU265_Support_Files]=>[JTAG Programming]=>[slaa149b.zip], and unzip that.
Go down to [Replicator Project & Sources for SpyBiWire]

I am waiting for my LaunchPad (which I ordered 3 months ago). I am now interested in doing another attempt of some sort.

Any comments? Questions? Possible cooperative assault?

--OCY

Hi everyone,

Re-re-reading again the Appnotes I think problem could arise with SBW capable devices, because after TEST going active, device starts in SBW mode and then I must go into JTAG4 mode

In this two-steps approach I'm missing something that causes MSP430 going into bypass mode.

I should try with a non-SBW device, I have one of these too. I'll tell you wath happened . . .

Rgrds

Fernando

Hi Fernando,

I am having the exact same problem as you.  I am implementing a custom MSP430 programmer like you.  I am using a MSP430F247 (No test pin, yes 4 -wire jtag, no spi-bi-wire) and using the SLAU320A document and source code as reference.

I am able to power on the device, reset the TAP, do a fuse check (TMS toggle twice), and get the JTAGID (0x89).  However, when I implement the IsFuseBlown() routine from the example source code  which does an IRSHIFT(IR_CNTRL_SIG_CAPTURE) followed by the a DR_SHIFT16(0xAAAA), I get a 0x5555 returned back from the TDO pin, which is TDI delayed by 1 TCK cycle.  This indicates that the fuse is blown, or I am in BYPASS mode.  I know the fuse is not blown because I can program the target MSP430 using a gang programmer, so somehow I must be stuck in BYPASS mode.  Have you any luck?  I will post my solution if I find one...

Michael

I figured out my problem...

When you do a fuse check (toggling TMS), you have to ensure that the TDI line is high (I had it low and that's why my fuse check didn't work and I was stuck in BYPASS mode).

Also note, the low phase of TMS during the toggle has to be a minimum 5 us.

Hi Mike,

Did you solve the problem that way? I think I've tried with both levels of TDI (unsucessfully) but I'm not so sure

In my hobbist experience I've worked with uC from different manufacturers, always building custom programmers for all of them (OTP, UV-EPROM, EEPROM, with external or internal Vpp, etc), but none of them so complicated as MSP430 family. The official documentation is also confusing regarding the use of TDI as alternate clock source and what levels should be taken in this pin when entering JTAG4 mode. Last month I archived all the MSP430 documentation, in the hope of new versions of the MSP430 Familiy Guide that someday gave me better clues

What I did (finally) is getting samples of the RSH08 family of microcontrollers from Freescale semiconductor, and I'm working my projects with this . . .

Please notice me if you have success with your approach, coz I will rescue all of the datasheets and get on work again !!!!

Very thanks for your suggestions

Regards

Fernando,

Yes I solved my problem that way.  It seems to me, that the MSP430 JTAG will be stuck in bypass mode until a fuse check is done correctly.  To ensure you are performing the fuse check correctly, make sure your JTAG signals look like Figure 1-12 in the "SLAU320A  - Revised Nov 2010" document.  My problem, again, was that my TDI was low, when according to figure 1-12 it should have been high.

Good luck!

Mike