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.

  • Resolved

MSP430F123: JTAG ID returned

Intellectual 600 points

Replies: 7

Views: 1221

Part Number: MSP430F123

I'm debugging a MSP430F123 that does not want to program.  Fist step was to look at the fuse check step and that seems to be ok.  Next step was to check the returned JTAG_ID.  The value (from SLAU320AB pg 64) should be 0x89 (binary pattern 10001001)  but the returned value is 0x91 as shown below  (MSB is the last bit as described in Fig 1-3 of SLAU320AB pg 9).  Could someone offer some insight here?  I could be doing something wrong but I can't see it.

  • Hi,

    I believe the issue here is with how your scope shot and Fig 1-3 of SLAU320AB were interpreted. The figure in SLAU320AB is a timing diagram, so it is showing the signals in the order that they are produced (not as a function of time technically). So, as you pointed out, the LSB comes first, and the MSB last. But the scope shot that you posted shows the signals as a function of time. In this case, the bit on the right was the first bit received (the signals move across the screen from left to right). Because the bits are shifted out LSB first, your scope shot corresponds to 10001001 (the MSB is on the left), which is 0x89. So you are getting the expected JTAG_ID.

    Regards,
    Nathan
  • In reply to Nathan Siegel:

    Hi Nathan,

    Figure 1-3 is not a timing diagram. There are no min/max values supplied for pulse widths (see Fig 1-8, 1-9) but it does show the sequence in which the bits are sent from the FET and the MSP. The scope traces are in the same order top to bottom as Fig 1-3 so TCK is Blue, TMS is Magenta, and TDO is Green. Since it is a scope trace, time increases from left to right. The flow of time in Figure 1-3 is also left to right since the TDI value is captured (TCLK) on the far left and restored on the far right. In my scope trace you can see that a fuse check occurs before the FET attempts to read the JTAG ID (look at the small trace above the detailed one) and it happens in the correct sequence. The sequence for the IR_SHIFT instruction is also correct and my interpretation of the data is valid. The bit on the far left was generated before the bit on the right so it was received first. This is an endian thing, the scope trace is little endian (10001001 or 0x19) so the big endian version is 10010001 of 0x91.

    Be that as it may, I did some more digging and it appears that the FET I am using has a glitch during low to high and high to low transitions. You can kind of see it in the jag in the TCK line but I really needed to zoom in on the transition to see it. This glitch was messing up what the MSP was seeing for the clock. I added a small cap from the TCK line to ground to filter out the glitch and it seems to be working now. Not an ideal solution but it will have to do.
  • In reply to Andrew Barnes:

    The glitch was a signal reflection.  Adding a 10 ohm series resistor seems to have fixed the problem.  I'd still like to know how the bits are transmitted from the MSP.  Either the documentation is wrong or the MSP is sending out the wrong JTAG id, or I'm wrong.  If I'm wrong please tell me why.  

  • In reply to Andrew Barnes:

    Hi,

    Thank you for documented what fixed the problem.

    As for the reading out of the JTAG ID, I think my previous explanation was a little confusing. Regardless of the figure in the JTAG User's Guide, the issue here has to due with the scope shot. When a signal is viewed on an oscilloscope, the signal moves from left to right. Because of this, the bits that were received first will be furthest right on the scope shot (this means the time actually decreases from left to right). This means that the bit furthest right is the LSB. So what you are seeing on the scope shot should be read as 10001001, or 0x89. Endianess shouldn't have anything to do with this, and it wouldn't matter either way because endianess is based on bytes, not bits or hex digits.

    Regards,
    Nathan
  • In reply to Nathan Siegel:

    You are right that the signal moves from left to right, this means that the bits on the left were received first (it's the oldest data). I've got 20+ years developing and debugging protocols with an oscilloscope. The documentation says that the LSB is sent first and the MSB last:


    Bit      1 2 3 4 5 6 7 8
    Value 1 0 0 0 1 0 0 1

    Normally we look at binary numbers with the LSB on the right so the value we received needs to be mirrored

    Bit      8 7 6 5 4 3 2 1
    Value 1 0 0 1 0 0 0 1

    This then needs to be turned into a hex number

    Bit      8 7 6 5 | 4 3 2 1
    Value 1 0 0 1 | 0 0 0 1
    HEX 9 1

    You can't take a bit sequence with the LSB on the left and convert it directly to hex because hex numbers have the LSB on the right. What you have done is make the LSB the MSB. The endian thing was simply to point to the bit order, lsb first or msb first.  For reference look at this.  The transmitted value is 0x4B with the B being transmitted first.  Using your approach the value would be 0xC2.

    So is the MSP sending the wrong code or is the documentation wrong.

  • In reply to Andrew Barnes:

    I've looked at SLAU320AB a little bit further and noticed that from the documentation, the IR_SHIFT macro shifts in bits on TDI LSB first but it does not say how the JTAG ID is shifted out on TDO (LSB first or MSB first). If what you say is correct then the bit order for the JTAG ID must be MSB first which is the same as the DR_SHIFT16 and DR_SHIFT20 macros. If the bit order is different for received and transmitted bytes in the IR_SHIFT instruction this would be an important detail to add to the documentation.

    Can you confirm this?

    Is there any particular reason the IR_SHIFT is LSB first but the IR_SHIFT16 and IR_SHIFT20 are MSB first?

  • In reply to Andrew Barnes:

    Andrew,

    The JTAG instruction register in the MSP430 family is realized as an 8bit wide shift register. While the TAP controller is in “CAPTURE-IR” state a fixed binary pattern is loaded into the JTAG_INSTR_REG and will be shifted out through the TDO output pin during loading a new instruction.
    In your case this would be the 0x89 for teh implemented JTAG version on the F123. When accessing the JTAG instruction register the MSB bit of the version pattern is shifted out first. As you can see on your scope shot. A JTAG instruction must be shifted in with the LSB first.

    A JTAG data register in the MSP430 family is realized as an 8bit or 16bit wide shift register. While the TAP controller is in “CAPTURE-DR” state a binary pattern from a source is captured into the selected JTAG data register (Selected through JTAG instruction) and will be shifted out through the TDO output pin during loading a new data pattern. The new pattern will be loaded onto the selected source if the JTAG instruction allows this. When accessing the JTAG instruction register the MSB bit of the captured pattern is shifted out first. A new JTAG data must be shifted in with the MSB first.

    So TDO you always see MSB first for IR_SHIFT and for DR_SHIFT but the order of bits for the pattern on TDI is different for both.
    I agree that it would help if figure 1-3 or the chapter describing the IR_SHIFT would mentioned that the shift out operations happens with MSB first. I will check with the document owner if this can fixed with the next document update.

    Best regards,
    Dietmar Walther

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.