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.

[RM57Lx LaunchPad] Connection failed and XDS110 not found

Other Parts Discussed in Thread: TPD4E004, TM4C1294NCPDT, SEGGER, RM57L843, TPS2553

Dear community,

I've an RM57Lx LaunchPad and one HDK. Previously the Launchpad and the HDK worked fine. Unfortunately, the Launchpad cannot be connected since this noon after the lunch break.

I was debugging a simple tutorial project on the launchpad with IAR EWARM IDE and another simple tutorial project on the HDK with CCS v6.1 at the same time. The Launchpad and HDK were connected to my laptop via a USB hub SSK:SHU028 (with 5V adapter).

Before the lunch break, I had stopped debugging on both devices (LaunchPad and HDK) but I only plugged out the LaunchPad from the USB hub whereas HDK remained connected to my laptop.

After lunch break, I plugged in the launchpad to the USB hub:

The XDS110 status LEDs (LED7, LED8) lighted up for about one second then died out. After that, the launchpad cannot even be connected to other PCs in the lab.

Can the launchpad be reset?

  • Hello Honig,

    Can you try to connect the Launchpad using CCS6.1 instead of IAR. Once your project is setup in CCS, open the target configuration and click on Test Connection to see if it can access the device at all. Let me know the results.
  • Hi Chuck,

    Should I reinstall the XDS110 driver? My laptop (windows 7, device manager) cannot detect the XDS110 device.

    Double click the target configuration file .ccxml, then click Test Connection:

    [Start: Texas Instruments XDS110 USB Debug Probe_0]
    
    Execute the command:
    
    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity
    
    [Result]
    
    
    -----[Print the board config pathname(s)]------------------------------------
    
    C:\Users\Administrator\AppData\Local\Texas Instruments\
        CCS\ti\2\0\BrdDat\testBoard.dat
    
    -----[Print the reset-command software log-file]-----------------------------
    
    This utility has selected a 100- or 510-class product.
    This utility will load the adapter 'jioxds110.dll'.
    The library build date was 'Nov 19 2015'.
    The library build time was '00:41:25'.
    The library package version is '6.0.83.0'.
    The library component version is '35.35.0.0'.
    The controller does not use a programmable FPGA.
    
    An error occurred while hard opening the controller.
    
    -----[An error has occurred and this utility has aborted]--------------------
    
    This error is generated by TI's USCIF driver or utilities.
    
    The value is '-260' (0xfffffefc).
    The title is 'SC_ERR_XDS110_OPEN'.
    
    The explanation is:
    An attempt to connect to the XDS110 failed.
    The cause may be one or more of: no XDS110 is connected, invalid
    firmware update, invalid XDS110 serial number, or faulty USB
    cable. The firmware and serial number may be updated using the
    xdsdfu utility found in the .../ccs_base/common/uscif/xds110
    directory of your installation. View the ReadMe.txt file there
    for instructions.
    
    [End: Texas Instruments XDS110 USB Debug Probe_0]
    

  • Hello Honig,

    Yes. Please install the drivers if not already installed. Once Installed do as you mentioned, double click the target config and test connection. My guess is that it will not be seen this way either.

    It may be that the XDS110 was damaged when it was unplugged from our laptop in some way (ESD or some other transient). If this is the case, the Launchpad may still be usable by populating the optional Hercules JTAG header in the upper left corner of the board and use an external debug probe such as an XDS200, XDS560USB, or other. This would work provided the MCU or other components have not been damaged.
  • Chuck,

    unplugged from our laptop in some way (ESD or some other transient)

    The USB jack is pretty well protected, with a TPD4E004 for ESD protection as well as a 4.7uF cap and series ferrites on the power rails to limit transients during plug/unplug.    Not that it's impossible - but I would suspect power delivery first.

    Honig,

    Please confirm if the hub that you plugged into is powered or not.  The Launchpad requires 500mA from the hub so you will likely need to plug it into a powered hub.  We've tried plugging it into a hub that isn't powered before say on a keyboard and it isn't able to work from one of these.

    Also, there is a footprint in which you can add a barrel jack and provide external power to the launchpad.   See

    If you don't have a barrel jack you can (very carefully) apply 5V across the J17 power jack pads on the footprint.  I suspect the board will light up when you do this.  Just don't get them reversed because the launchpad is not protected against a reverse power condition!  the +5V side is closest to the JTAG header and you can see it is connected through the PTC1 (over current protection device).

    Here is a picture showing which side is +5V_JACK (Highlighted):

    If the board powers up when powered through this optional barrel jack then it should be able to connect.   If not then I think it is damaged somehow.  

    Another problem may be the CURR LIM circuit.

    There is an LED for CURR LIM indication just to the right of the USB jack.  Check to see if it is on.

  • Honig,

    Could you check the following in your RM57Lx Launchpad?

    Connect to your PC via USB cable.
    In a command prompt, go to CCS installation directory as following:

    C:\ti\ccsv6\ccs_base\common\uscif\xds110 and run the following command:

    xdsdfu -e

    The result should be:

    If the Serial Num is reported as 00000000 than it will be necessary to reprogram the firmware by using the following command.
    xdsdfu -m
    xdsdfu -f firmware.bin -r

    xdsdfu -m
    xdsdfu -s HLR57L00 -r

    You can now re-run xdsdfu -e, this time the correct serial number should be reported.

    At that point, try in CCS to re-run the connection test.

    Please let me know the result.

  • Hi Jean-Marc,

    XDS110 couldn't be found.

    D:\ti\ccsv6\ccs_base\common\uscif\xds110>xdsdfu -e
    
    USB Device Firmware Upgrade Utility
    Copyright (c) 2008-2015 Texas Instruments Incorporated.  All rights reserved.
    
    Scanning USB buses for supported XDS110 devices...
    
    
    Found 0 devices.
    
    D:\ti\ccsv6\ccs_base\common\uscif\xds110>

  • Hi Anthony,

    > Please confirm if the hub that you plugged into is powered or not. <

    Yes, it is powered with a 5V adapter.

    > There is an LED for CURR LIM indication just to the right of the USB jack.  Check to see if it is on. <

    The CURR LIMIT LED is off. The +5V LED6 is always on. The LED7/8 (XDS110 STATUS) are off.

  • Hi Chuck,

    > Please install the drivers if not already installed. <

    I reinstalled CCS v6.1, but I was not sure if the XDS110 would be automatically reinstalled correctly at the same time. Does TI provide a stand-alone XDS110 driver setup package for windows 7 64-bits? And how to check if a specific driver is correctly installed without an intact target device?

    > It may be that the XDS110 was damaged when it was unplugged from our laptop in some way (ESD or some other transient). <

    Possibly not. I noticed that the RM57Lx LaunchPad would be damaged when it was plugged in again to my laptop via the USB hub (the LaunchPad powered with a 5V adapter) after the lunch break: The XDS110 status LED (LED 7/8) lighted up and died out. After that, I couldn't find the XDS110 port in the device manager (Windows 7).

    By the way, does ESD mean "electrostatic discharge"? Could this transient be prevented by the current limiting circuit?

  • Hello Honig,

    Yes, by ESD I mean electrostatic discharge; however, Anthony believes there is sufficient protection against this sort of issue that it shouldn't be the problem. Given he is the board designer, I trust this is true.

    Have you tried plugging directly into your PC? As Anthony mentions, this device is very "power hungry" and providing even slightly insufficient power can cause the voltages to dip resulting in unpredictable operation of the components including the XDS110. Perhaps you could attempt to connect a power supply as Anthony suggested if you cannot plug directly into your PC? Note that the supply should be capable of greater than 500mA supply current.

    Are there any other LEDs ON on the board when you connect using the USB Hub? Do the XDS110 LEDs flash on briefly every time you plug into the USB Hub or did they do it the one time then never again? This isn't clear to me in your description of what has transpired and what you might have tried already.
  • Hi Honig,

    U3 which is right next to the USB jack is an ESD protection device, TPD4E004 which is spec'd for +/-15KV.

    Of course this is just one entry point the most likely one that you would just walk up to and touch.  But if you walk up and touch other parts of the board there could still be damage.   I just tend to think this isn't likely compared to other potential issues.

    I have the same question as Chuck regarding plugging into the same jack on the PC that was working before.  Also it would be good to use the same USB cable as before.  If you plug the board into the PC the same way as it was working before - will it still work?


    Not seeing any activity on LED7/8 would be indicative that the software on the XDS110 emulator isn't running.
    So you would want to check what JM suggests - using the XDSDFU utility.   Let us know what is reported back when you issue the XDSDFU -e command.   

    EDIT: I see you tried what JM asked and reported no devices found.   That isn't a good sign but it could still be a bad USB cable or connection.    If you rule these things out, and you rule out a problem with the power supply as described below - there is one other thing you can try which is to try the procedure described in the 'README' file ccsv6\ccs_base\common\uscif\xds110\ReadMe.txt:

    *** Recovering a Bricked XDS110 Without JTAG ***

    In the case that your XDS110 fails to enumerate as a USB device, or it
    fails to enter DFU programming mode, you can attempt the following steps
    to force it into DFU mode to recover:


    1) Ground the JTAG TDO pin of the XDS110's Tiva CPU.  This is pin 97
    on the 128 pin device.  This is a JTAG pin for flashing the XDS110 via
    JTAG; it is not the JTAG TDO pin of the debug target. If the board has
    a JTAG header for flashing the XDS110 you may use that, otherwise you
    can ground the pin on the device. (Check the TM4C1294NCPDT datasheet
    for the pin location; it is located on a corner and easy to access.)

    2) Unplug and re-plug the XDS110 into the host PC while the pin is grounded.

    3) The XDS110 should now be in DFU programming mode and you can flash it
    using the xdsdfu utility as detailed above.

    Note that this feature is currently only implemented in the XDS110 boot
    loader that was first available in emupack 6.0.15.0. If your XDS110's
    boot loader is an earlier version, this procedure won't work. In the boot
    loaders from emupack 5.1.537.0, the target JTAG TCK pin was used instead.
    If your device used that version of the boot loader, try the procedure
    by grounding the target TCK pin. If your XDS110's boot loader is an even
    earlier version, this procedure won't work at all, and you'll need to use
    JTAG to recover.

    Here is a picture from the launchpad layout - there are easier places to contact the XDS110 JTAG pins than on the device itself, because the pitch of the 128QFP is tiny.   The 10 pin surface mount header in the picture below is on the back side of the PCB.  It's pads are covered with soldermask so you will need to scrape some of the soldermask away with a razor knife before contacting - but this is still easier than trying to contact directly on the QFP.      I labeled TCK, TDO, and GND for you in the image.   

    Just remember that this is an image looking down through the board from the top so in real-life when you flip the board over, the header will be mirrored

     

    A recent CCS update pushes new firmware to the XDS110 and I suppose something could have gone wrong during that update - in which case you would need to use the XDSDFU utility to reprogram it.

    JM noticed the other day that one board here was flaky but the USB jack was placed wrong.  From your photo - I don't think you have this issue on your board.   In fact I looked at the photo and didn't really see anything that looked bad.

    Aside from these items,  if you have a voltage meter please check the voltages for the +5V, +3.3V and +1.2V rails.

    The +5V and +3.3V rails can easily be measured at the large exposed pads on JP2 and JP3 which are right next to the USB jack.   There is also a GND point on the edge of the board you can use as the voltage reference.

    The +1.2V rail has a test point above the Hercules device, it is right below the letter '2' in the name '337 ZWT LAUNCHPAD XL2'.   it is labeled +1.2V.  You can use the same GND point as the reference. 

    Let us know what the power rails read.

    Best Regards,

    Anthony

  • Hi Chuck,

    Have you tried plugging directly into your PC? As Anthony mentions, this device is very "power hungry" and providing even slightly insufficient power can cause the voltages to dip resulting in unpredictable operation of the components including the XDS110.

    Yes, I have tried connecting LaunchPad to my laptop and a PC in the lab directly without the USB hub. Neither was able to detect the XDS110 port. Note that my USB hub has a 5V adapter.

    This isn't clear to me in your description of what has transpired and what you might have tried already.

    Only one LED, the LED6 (+5V), is ON on the board no matter when the LaunchPad is directly plugged into a computer, or via a USB hub. Two LEDs (LED7/8) flashed on briefly when the LaunchPad was plugged into the USB Hub at that time, then never again.

  • Hi Anthony,

    I have the same question as Chuck regarding plugging into the same jack on the PC that was working before.  Also it would be good to use the same USB cable as before.  If you plug the board into the PC the same way as it was working before - will it still work?

    When the board is plugged into a PC the same way as it was working before, it doesn't work any more.

    That isn't a good sign but it could still be a bad USB cable or connection.

    It could still be an issue of the cable and the connection interface hardware, but the possibility would be quite small. I would like to rule these things out and follow your instructions on *** Recovering a Bricked XDS110 Without JTAG ***.

    By the way, would it be safer and easier to recover a bricked XDS110 with a JTAG? I have a J-Link EDU emulator and bought several 20-PIN-breakouts.

  • Hi Anthony,

    1) Ground the JTAG TDO pin of the XDS110's Tiva CPU.  This is pin 97
    on the 128 pin device.  This is a JTAG pin for flashing the XDS110 via
    JTAG; it is not the JTAG TDO pin of the debug target. If the board has
    a JTAG header for flashing the XDS110 you may use that, otherwise you
    can ground the pin on the device. (Check the TM4C1294NCPDT datasheet
    for the pin location; it is located on a corner and easy to access.)

    In page 16 of the schematics file of LaunchPad "LAUNCHXL2_570LC43_RM57L_SCHEMATICS.pdf": J19 not intended for normal use. Locate on Back Side / Cover in SM. From the TM4C1294NCPDT datasheet (screen-shot below), I can locate the PIN 97 (PC3/TDO/SWO). Could I use a wire to connect this pin to GND? It is quite tiny.

    Note that this feature is currently only implemented in the XDS110 boot
    loader that was first available in emupack 6.0.15.0.

    How to check the emupack version? In CCS v6.1, Help -> Installation Details : TI Emulators 6.0.14.5. Should I click "Update" and update to version 6.0.83.0?

  • Hi Honig,

    The JTAG header J18 is to debug the Hercules device.   You can try this - it would possibly allow you to use the launchpad even if the XDS110 is bricked.  But, the pinout is the TI CTI 20 pinout.  I am not sure if it is compatible with the Segger JLINK and you may need to build an adapter.  You can see the pinout on the board in the board schematic.

    Yes you are right that we labeled J19 as not intended for normal use and we also covered the pads with soldermask to prevent them from accidentally being contacted by most users.  But they are useful for recovering the bricked XDS110.   This is the JTAG header for the TM4C129 device that is used for the XDS110 logic.
    The TM4C if it is not damaged supports a USB 'DFU' type bootloader.  If that were running then you would see it show up when you type 'xdsdfu -e'.   Since it doesn't show up - and if you rule out issues with the USB cable and USB jack, then the next most likely thing is somehow bad firmware got into the TM4C129.    Using the recovery procedure,  either the ROM bootloader or the XDS110 bootloader firmware should be invoked which will make it visible with XDSDFU -e again.  then you can use the XDSDFU commands to reprogram the firmware for the TM4C129 again.  

    If this procedure doesn't work,  then it's probably dead / damaged.  you could try to remove and resolder the USB jack just in case the problem is a short under the jack.  As JM pointed out if the jack gets pushed back this is common, but maybe something got under there accidentally and is shorting.  The pitch of the micro USB jack is very very tight.   You'll need a soldering setup with a microscope to even see what you are doing.

    -Anthony

  • Hi Anthony,

    Anthony F. Seely said:
    The JTAG header J18 is to debug the Hercules device.   You can try this - it would possibly allow you to use the launchpad even if the XDS110 is bricked.

    Could I use JTAG header J18 to recover the bricked board? Which pin of JTAG header J18 is connected to the PIN 97 (PC3/TDO/SWO) of TM4C1294NCPDT? I'd like to connect that pin of J18 to GND via a wire instead.

    Anthony F. Seely said:
    But, the pinout is the TI CTI 20 pinout.  I am not sure if it is compatible with the Segger JLINK and you may need to build an adapter.  You can see the pinout on the board in the board schematic.

    Segger JLINK has a 2.54mm Pitch 20-pin JTAG, while the launchpad has a 1.27mm Pitch 20-pin JTAG header. Thus, I'd like to connect them via a DIY 20-pin cable. What else should be taken into account? Why do I need to build an adapter? Does the launchpad need the +5V DC adapter?

  • Honig,

    honig said:
    Could I use JTAG header J18 to recover the bricked board?

    Not if the problem causing the bricked board is with the XDS110 (TM4C129).   There are 2 different JTAG headers - one for the Hercules (J18) and one for the TM4C.    The recovery procedure in the readme requires that you use the JTAG for the TM4C which is the smaller JTAG on the back side of the PCB.

    What you can do with J18 is to (possibly) debug the Hercules and 'use' the bricked board without the XDS110 on board, but with a Segger JLINK.   You will need to construct the DIY adapter pretty carefully.  If you have the ability to purchase another laucnhpad - it may be faster / easier to do that. 

    When you use the Launchpad with the Segger JLINK you will still need to power the launchpad.  If it is powering up with the USB cable you can probably continue to use the USB cable for power,  or else you can use an external +5V DC adapter.


    One problem using the Segger (or any external) JTAG emulator on J18 is that if you were using the UART on the launchpad - the one connected to the XDS110 - you will lose this capability if you do not actually recover the XDS110.


    Best Regards,

    Anthony

  • Anthony,

    Anthony F. Seely said:
    If you have the ability to purchase another laucnhpad - it may be faster / easier to do that. 

    Another RM57Lx LaunchPad or an upgraded board with additional peripherals?

    Anthony F. Seely said:
    The recovery procedure in the readme requires that you use the JTAG for the TM4C which is the smaller JTAG on the back side of the PCB.

    Oh.. I could not even see that "smaller" JTAG. It is covered. Could I simply connect PIN97 to GND with a wire, so as to recover the bricked board?

    Anthony F. Seely said:
    if you were using the UART on the launchpad - the one connected to the XDS110 - you will lose this capability if you do not actually recover the XDS110.

    Yes, the UART capability is blocked, when XDS110 is bricked.

    Anthony F. Seely said:
    with a Segger JLINK.   You will need to construct the DIY adapter pretty carefully

    Is it really necessary to construct a DIY external +5V DC adapter? I was able to debug RM57Lx LaunchPad in IAR EWARM IDE with Segger JLINK EDU connected to J18 and without plugging the miniUSB (XDS110), moreover, without connecting the board to a+5V DC adapter. However, it was pretty slow, when some strings were printed out to the console (printf("...")).

  • Hi Honig,

    honig said:
    Another RM57Lx LaunchPad

      Yes,  they're not too expensive, and if you have a school project with a hard deadline then having a backup board in case something goes wrong may be a good idea.

    honig said:
    Oh.. I could not even see that "smaller" JTAG. It is covered. Could I simply connect PIN97 to GND with a wire, so as to recover the bricked board?

    Yes we covered this smaller jtag with soldermask so it's not readily apparent that it is there.  also it is near one of the booster pack headers. 

    I would recommend scraping off some of the soldermask with a razor knife and soldering to these pads.  You *could* solder directly on the QFP of the TM4C129 but the pitch is small.  You would need a very good iron and a microscope to do this correctly.   Whereas the 10 pin jtag header is a lot easier to contact and solder to once you scrape off the solder mask.   But that's just what I would do.  You of course should use your own judgement.

    honig said:
    Is it really necessary to construct a DIY external +5V DC adapter? I was able to debug RM57Lx LaunchPad in IAR EWARM IDE with Segger JLINK EDU connected to J18 and without plugging the miniUSB (XDS110), moreover, without connecting the board to a+5V DC adapter. However, it was pretty slow, when some strings were printed out to the console (printf("...")).

    Hmm.  I am a bit surprised that you were able to debug the board without providing power to it.  I would think you would either need the USB or the +5V adapter.     In fact this may have caused some damage to the TM4C129 because the JTAG pins on the header J18 are connected to the TM4C, and if the TM4C wasn't powered, but the external jtag adapter was driving voltages into the TM4C - this would be operating it outside the abs max rating potentially on those pins.   Probably wouldn't damage the device but it may have.

    I'm also surprised that you didn't need an adapter for the JLINK because the pinout of J18 is a TI pinout.
    Maybe you can send info on the JLINK pinout that you used..?

  • Hi Anthony,

    Anthony F. Seely said:
    I'm also surprised that you didn't need an adapter for the JLINK because the pinout of J18 is a TI pinout.

    Sorry for my ambiguous text... An adapter is definitely needed for my J-LINK EDU emulator. However I did not need one more adapter exclusively for RM57Lx LaunchPad when debugging with J-LINK. In other words, I meant that only one +5V adapter was plugged to J-Link emulator instead of the board.

  • Hi Honig,

    Ok - I can understand the adapter for JTAG.


    But for power - where is the Launchpad's power coming from in this configuration? 
    Is it coming from the J-LINK through J18? 

  • Dear Anthony,

    I have the same problem. And I pluged XL2-RM57 in laptop USB and  measured voltage value with a voltmeter: +5V Pin is 2.4V, +1.2V Pin is 1.1V. So th e voltage is not right.

    Then I Connected XL2-RM57 to an adjustable power with +5V. After I adjusted current limit up to 600mA, I smell of a strange smell......Maybe some IC got burnt.

    I have 4pcs XL2-RM57 with the same problem. How can I repair this problem?

    Best Regards,

    Finley Quan.

  • Finley,

    can you provide either pictures or diagrams demonstrating where you measured the voltages and where you connected the power supply? This would be helpful in determining what might have happened.
  • Hello Chuck,

    I have found the problem. It is +3.3V not right. When I removed RM57L843, everthing goes right.
    Maybe RM57L843 has been brokendown.
    But this problem appears so more. It seems abnormal......

    Best Regards,
    Finley Quan
  • Same problem for me, it seems that tps2553 is broken or something else,
    there is a solution?