Hi,

  Refer to the XDS110 Debug Probe User's Guide https://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_xds110.html and go to Updating the Firmware section. 

Updating the Firmware

Automatic update

When using ccsv8.1.1+ or ccsv8.1.0 with TI Emulators package version 6.0.14.5 or newer, the firmware on the XDS110 is updated automatically when connecting from inside CCS.

Note that the firmware is not automatically reverted to a prior version unless there's been a major change. For most scenarios, all changes are backwards compatible to ensure this works. If a change is needed that is not backwards compatible, then the major version numbers will change as a flag that it can't work.

Examples:

• CCS supports firmware 2.3.0.12, XDS110 has firmware 2.3.0.8 → XDS110 will be updated to 2.3.0.12
• CCS supports firmware 2.3.0.12, XDS110 has firmware 2.3.0.14 → XDS110 will not be reverted
• CCS supports firmware 2.3.0.12, XDS110 has firmware 2.4.0.1 → XDS110 will be reverted to 2.3.0.12

Manual update

If manual updating or diagnostics is required, using a Windows host is highly recommended. Close any instances of CCS that are running in your system. Open a Windows Command Prompt and issue the following commands:

1. Go to the directory where the utility is installed:

C:\>cd C:\ti\ccs1040\ccs\base\common\uscif\xds110

2. Run the configuration just to make sure a XDS110-class debugger is connected (or to list how many are connected) and what is the firmware revision installed on it:

C:\ti\ccs1040\ccs\base\common\uscif\xds110>xdsdfu -e

3. Put the XDS110 in DFU mode:

C:\ti\ccs1040\ccs\base\common\uscif\xds110>xdsdfu -m

4. Run the updater, passing the firmware file and resetting the debug probe afterwards:

C:\ti\ccs1040\ccs\base\common\uscif\xds110>xdsdfu -f firmware_3.0.0.16.bin -r

In case of a bricked pod

In certain scenarios there is a chance your Pod or Launchpad becomes bricked by the firmware update. Check the Troubleshooting section below for additional details.

Finding and updating the serial number

When using multiple debug probes in the same host, in general it is necessary to properly differentiate each debug probe by serial number.

To find out what is the serial number of all connected debug probes, follow steps 1 and 2 above

If you want to set the serial number to a specific value:

1. Unplug all other debug probes from the host

2. Follow steps 1 through 3 above

3. Set the serial number suffix (RECOMMENDED):

C:\ti\ccs1040\ccs\ccs_base\common\uscif\xds110>xdsdfu -n 4567 -r

Thank you for your response.

1º: For my application I am not going to use the product "TMDSEMU110-U" because the goal is to develop my own debugger that will go on my PCB, so I want to know if the steps described in your answer would be the same for any other microcontroller.

2º: I want my microcontroller to be used for other functions and not only for debugging, so I would like to know if you provide the source code for the file "xdsdfu -f firmware_3.0.0.16.bin -r".

3º: I realised that for my application I don't need the debugging part. It would be enough with the process of running the boatlader as explained in these tutorials: https://www.ti.com/lit/an/spna183/spna183.pdf

https://www.ti.com/lit/an/spna189/spna189.pdf?ts=1719743482175&ref_url=https%253A%252F%252Fwww.google.com%252F

Juan Jacinto Montenegro said:

1º: For my application I am not going to use the product "TMDSEMU110-U" because the goal is to develop my own debugger that will go on my PCB, so I want to know if the steps described in your answer would be the same for any other microcontroller.

For the onboard XDS110, tt would have to be based on a supported device like the TM4C1294NCPDT

Juan Jacinto Montenegro said:

2º: I want my microcontroller to be used for other functions and not only for debugging, so I would like to know if you provide the source code for the file "xdsdfu -f firmware_3.0.0.16.bin -r".

We do not provide the source code for the firmware

Juan Jacinto Montenegro said:

3º: I realised that for my application I don't need the debugging part. It would be enough with the process of running the boatlader as explained in these tutorials: https://www.ti.com/lit/an/spna183/spna183.pdf

I would need the device experts to comment on this.

Thanks

ki

1º: As I mentioned earlier in the post, I am working with the LAUNCHXL2-RM46, so I need a list of compatible devices to be able to perform the steps described in the previous answer.

2º:I am sad to know this because it is a limitation for developers and programmers. Even with this limitation, is there any way I can use my microcontroller for other functions and not only for debugging?

3º:I would like you to discuss this issue with your expert as this information I have passed on to you is explained by a famous TI_GURU as "QJ Wang".

I would like your answers to give some detailed solutions to my questions and not just short statements. Thank you

Hi Jaun,

Juan Jacinto Montenegro said:

3º: I realised that for my application I don't need the debugging part. It would be enough with the process of running the boatlader as explained in these tutorials: https://www.ti.com/lit/an/spna183/spna183.pdf

The XDS debuggers that will provide on Launchpad's or HDK boards are for easy debugging purpose only. You don't need to include these XDS emulator IC's in your PCB board for mass production.

Please refer below thread from QJ:

(+) WEBENCH® Tools / TMDX570LC43HDK : Can I get the CPLD source of TMDX570LC43HDK? - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

 So, what customers will do is that they will remove these XDS emulator IC's in their final custom board and instead of this they will provide a provision for 20-pin ARM JTAG connector for direct code flashing into the Hercules controllers. So, we don't provide the source code of XDS emulators to the customers for their customization because they will be used only on our TI-specific Launchpad or HDK boards and not for end products.

So, if you want to use UART or CAN or Ethernet or SPI etc. bootloaders in your application then you should need to place them in the starting sectors of the flash only and on top of that you can place your main application like QJ described in his application notes.

CAN Bus Bootloader for RM46 MCU (ti.com)

UART Bootloader for Hercules RM46 MCU (ti.com)

--
Thanks & regards,
Jagadish.

Juan Jacinto Montenegro said:

1º: As I mentioned earlier in the post, I am working with the LAUNCHXL2-RM46, so I need a list of compatible devices to be able to perform the steps described in the previous answer.

TM4C1294NCPDT and MSP432E401YTPDT (both 128 pin) are compatible for any XDS110 design.

Juan Jacinto Montenegro said:

2º:I am sad to know this because it is a limitation for developers and programmers. Even with this limitation, is there any way I can use my microcontroller for other functions and not only for debugging?

What is the goal of obtaining the XDS110 source code? Do you wish to modify the XDS110 firmware so that you can use the XDS110 device for other things than just XDS110 debug?

Yes, this has been one of the questions from the beginning of the post, to get the C libraries from the XDS110 JTAG to load and install them in the TM4C129ENCPDT micro, which will act as compiler for my main microcontroller (RM46). So the goal is to get the source code so that the TM4C129ENCPDT microcontroller doesn't act only as a debugger and can be used for other functions.

Hi @Ki,

Will you provide the response, whether it is possible to provide source code for TM4C129ENCPDT or not?

--
Thanks & regards,
Jagadish.

I am waiting for an answer. Thank you

Sorry, we do not support custom modifications of the XDS110 firmware. This also means that we do not provide the source code for it.

Is there no way I can use my microcontroller as a debugger, and still use this microcontroller for other functions, such as developing my own code? I mean, can I put the binary code from the XDS110 into the microcontroller and still use it?

Juan Jacinto Montenegro said:

Is there no way I can use my microcontroller as a debugger, and still use this microcontroller for other functions, such as developing my own code?

It may be possible but we do not support this scenario.

If Texas Instruments does not support this problem, who does? Because the problem of not getting information from the binary file is being imposed on me by Texas Instruments