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.
I have been using the MSP-FET430UIF debugger without any issue. When i switched to a dell latitude, I was able to flash code to the target using 'download and debug' on IAR kickstart. However the next time, i tried to flash, I received a 'failed to recognise hardware' error. I checked that the voltage on the JTAG (on the debugger side) dropped to 1.5 V from 3 V. The 'mode' light does not momentarily flash red upon connecting to the computer either. I verified that the target is working fine. Are there known reasons for why this might occur? is there any way i can salvage the debugger or is there some sort of fuse that i might have blown that i can reset? Thanks for the help.
Hi Vikram, if really broken ask TI about this issue from E-store help. Before to do please try on another pc, may be you have a broken USB, connecting other active peripheral they work? Try measure USB voltage. Full schematic of UIF is available and can be you broken votage regulator but I can think on a pc failure before or software update so try downgrade. Please do some cross check to see what is broken.
Regards
Roberto
Thanks for the response Roberto. I did try it on another PC with various combinations of USB and JTAG cables. The output VCC is still the same. I will scan the pins more in detail. I was wondering if the software caused something on the hardware to blow up while downloading through IAR kickstart.
What does VCC say if you remove the target MSP? Still dropped?
It's possible that the last version of software you flashed onto the chip causes such an extraordinary current consumption (e.g. by letting two port pins work against each other) that the VCC supply drops.
What about the UART demo? Old UART software for the original LaunchPad has the RX and TX lines swapped against newer LaunchPad versions (because the latest devices have a hardware UART with swapped RX and TX pins). So maybe the FETs UART and the MSPs UART are working against each other.
Or something like that.
Thanks for the reply Jens. The problem persists whether the target MSP is connected to the JTAG or not. I checked the voltage from the JTAG cable connected to the debugger (without the target). The figure can be viewed at: http://db.tt/y6ZCiYQl
I am not familiar with what are the expected voltages from the debugger-JTAG, but i would expect Vcc-GND to be 3V while it is showing 0V now. Can i get a bit of insight into what could have gone wrong? Is there a simple reset mode or something? Thanks.
Measuring voltage should be between PIN9 (GND) and any other pin. Pin1 is TDO/TDI.
Well, there's always apossibility of mirroring the connector (is the is ththe board jumper view (top view) or the cable conenctor view (bottom view).
At least according to th enumbering in your drawing, you never measured VCC/GND which would have been Pin2-Pin9
However, a voltage on VccExt will cause to mimick this voltage for the JTAG pin logic. If unconnected, well, I don't know whether it will eb pulled up to the configured FET output voltage then or what else to expect.
Of course there's always a possibility that you burnt the programmable voltage regulator of the FET
A look at the schematics of the FETU430IF (the only one I have here) shows two possible reasons for a failure.
First, the TPS76601D (U3) may be damaged and unable to provide the wanted output voltage for the JTAG I/O and VCC. Another possibility is that the circuit for generating the fuse-blow votlage is rampaging . It is a stepup-regulator and may permanently short VCC through an inductor to GND, loading VCC up to the point the voltage breaks down. In this case, the FETs MSP itself is not running on the desired 3.6V (which is independent of the JTAG VCC output!) and the reference fails, so the adjustment of th eI/O voltage falsely detects a high output voltage and regulates it down.
The latter case might be detected by checking the current on USB VBUS (or the VBUS voltage, which should be 5V)
Several more reasons are possible, yet these are the most likely ones.
Vikram Hrishikeshavan said:Thanks for the reply Jens. The problem persists whether the target MSP is connected to the JTAG or not. I checked the voltage from the JTAG cable connected to the debugger (without the target). The figure can be viewed at: http://db.tt/y6ZCiYQl
Hi Vikram, I hope from your writing you checked another cable, so my Hipothesys can be of current draw from ground, do some other measure:
Disconnect from PC, measure continuity from ground pin to USB ground and post result.
If no ground path then some current drained through ground and possibly has broken a USB fuse or some pcb track.
Voltage you measured on pin came from what reference? Where is connected ground to voltmeter?
Still vcc-vss is zero or near zero?
If ground continuity is ok then connect UIF to pc without target and measure VCC JTAG gnd voltage from PC ground ( get it on a rear connector like USB shield, VGA or HDI connector).
DO these measurement then we can try some cures to your trouble.
Regards
Roberto
@ Jens:
1) The picture i posted was from the cable connector view (which is the right view i suppose)
2) I measured all other pins with pin 9 (GND) and never registered a voltage except with Pin 1. So, Vcc-Gnd is 0 V.
3) As you suggested, i looked at the voltages from TPS76601D (U3).
So it looks like this regulator might be damaged since it is not providing any output voltage. The VBUS voltage however seems fine.
@ Roberto
1) I checked different cables and different PCs, so it is most likely a problem with the board.
2) There is continuity from JTAG ground to USB ground and other ground pins that i could gather from the FET schematic.
3) The voltage i measured came using JTAG ground as reference. (PC ground also gives same result).
4) I measured VCC-JTAG from PC ground and obtained same result. (hope i did not confuse what you suggested).
another thing, the ESD suppressor (U12 in schematic) seems to have a problem:
Looks like the board is damaged. I am however concerned that this problem started over a simple debugging routine via IAR kickstart in a Dell laptop. A new debugger might also be destroyed the same way. I just want to know what mistakes i could have made so that i dont repeat it.
Thanks for all the help! Really appreciate it.
One reason why the output of teh TPS76601 is 0V might be that VCC_Ext is grounded. The the FET tries to mimick this as signal voltage. Which of course won't work properly. I don't kow th eFETs internal firmwae, so I don't know whether this situation is handled properly or may indeed lead to 0V high-voltage.
Teh suppressor thing sounds weird. The GND side should be connected to GND and therefore no voltage is expected there at all if measuring to GND. It almost looks like the GND wire form the ESD part to PC GND is broken.
However, this may indeed happen. As you noticed yourself, PC GND and USB GND and MSP GND are identical. When using an external power supply, there is a chance that its GND level is different from PC GND, causing some current to flow. It is the same effect that may make HIFI stations to humm with 100Hz. GND potential differences and maybe even phase differences. Especially if the MSp power supply is connected to a different phase of a 3-phase power network than the PC. This kind of problems can not only destroy the target board or the FET but also the USB controller or the PC mainboard. In this case, only an RF based FET (like the ones from Olimex) or an USB isolator will prevent problems (but then, the isolator requires a power supply too, so a cheap version may introduce the very same problem)
So the issue is sorted out. It was a software issue.
1) The FET was initially working on an older version of IDE (v5.3) where the PC recognises it as a VCP COM port.
2) When connected to a newer version of the IDE (v5.4), a new firmware was updated to the FET and it changed to a CDC COM port. In this version, there is no Vcc output from the JTAG unless one is about to 'download and debug' from the IDE. Unaware of this, i thought there was a hardware problem and posted here initially.
3) To switch back to the old IDE version, one has to downgrade from MSP430.dll V3 to V2.
Now the Vcc output is fine. I was just not aware of this different version problem. TI should have made it more clear.
Thanks for all the help Jens and Roberto.
Well, we learned something too now: there is an unexpected and incompatible change in the behaviour of the FET between IDE V5.3 and V5.4.Vikram Hrishikeshavan said:Thanks for all the help Jens and Roberto.
For future reference, as I know this has been a source of confusion lately:
IAR version v5.4 and higher as well as CCSv5 use the new MSP430.DLLv3 for the FET tool. When you first use CCSv5 with the MSP-FET430UIF, you will receive a large pop-up message requesting a firmware update. This message details how this is a major update and that if you proceed, you will have to do a manual downgrade using the downgrade utility if you want to go back to using the FET tool with an older IDE version. Please read all of this message before you click to proceed. Also note that if you have very old FET hardware (no v1.4 sticker on the bottom) then you will need to take one additional step to upgrade your firmware (detailed on the wiki here under Rev. 1.3 update procedure: http://processors.wiki.ti.com/index.php/MSP_Debug_Stack#Upgrade_process_to_MSP430.DLLv3)
The way you can tell which firmware version is currently loaded in your FET is by the LED sequence (v2 = red-red-red-green, v3 = just green), and by looking in device manager under Ports to see how the FET has enumerated (v2 = MSP-FET430UIF - VCP, v3 = MSP-FET430UIF - CDC).
For more information about DLLv3, please see the wiki: http://processors.wiki.ti.com/index.php/MSP_Debug_Stack
Regards,
Katie
**Attention** This is a public forum