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.
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.
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.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Dudley Hiller:
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.
I can't get you clearly. Can you put some picture? Are you asking about JTAG Chain for programming?
Here is the connection:
If the post helped solve your issue, please click on the 'This resolved my issue' button.
In reply to Eason Zhou:
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.
FRAM reads are not destructive. If your FRAM drop out bits after reading. I advice you to use MPU to protect it.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.