• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 78 subscribers
  • Views 217 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.

MSP430FR5949: MSP430FR5949IRH JTAG will not repond

Dudley Hiller
Prodigy 230 points
Part Number: MSP430FR5949

I am developing a high volume FRAM programming solution for A GM Ventilator controller. I cannot get the JTAG to respond for device type MSP430FR5949. I have the sample in a socket adapter that works fine for device type MSP430FR5725RHA. The two devices have identical pin functions except for pin 30 that should not matter.

If am wondering if there are any other pins required to wake up the JTAG or something that is keep the JTAG from responding on the MSP430FR594.

It seems that the TDO just stays Hi-Z.

Once again this is for a GM Ventilator controller, so my need for technical help is rather urgent.

 

  • 0
    Prodigy 230 points

    I should also mention that the MSP540FR5949s will not even bypass. So there must be something that as totally disabled the JTAG on this part. So it acts as if the JTAG is not even there.

  • 0 in reply to Dudley Hiller
    Prodigy 230 points

    I got the JTAG to come to life intermittently but I have to go through the Figure 12. JTAG Access Entry Sequences (for Devices That Support SBW) hundreds of retries, and eventually it works.

    But this is not going to be a reliable high volume procedure.

    Any advice???

  • 0 in reply to Dudley Hiller
    TI__Mastermind 32920 points

    Hi, 

    I can't get you clearly. Can you put some picture? Are you asking about JTAG Chain for programming?

    Here is the connection:

  • 0 in reply to Eason Zhou
    Prodigy 230 points

    You are only pasting documentation I already have. I already know this stuff. 

    After trial and error I was able to get the device to bring up the JTAG reliably, but in a rather unconventional way... I put a strong pull-down in RESET and a strong pull-up on TEST (330-ohms) in the programming device (Teradyne TS124LH) I am using. This seems to work as long as the strong PUs and PDs are connected before power up.

    I am now seeing a new problem, and I am doing a band-aid work around for it. Can TI please comment?...

    My understanding is that FRAM reads are destructive, and a write-back is required. But the slau320ai.pdf document seems to imply that the write-back is automatic. Well apparently not. If I write a test pattern into the entire code memory, then read it back many times, it start to drop out bits. So I write the FRAM read-back verify then write it back manually as a final step.

  • 0 in reply to Dudley Hiller
    TI__Mastermind 32920 points

    Hi,

    FRAM reads are not destructive. If your FRAM drop out bits after reading. I advice you to use MPU to protect it.

    Eason

**Attention** This is a public forum