TMS320F280049C: TMS320F280049

Kevin Allen18 can you help me ??

Hi Chirag,

Sorry for the delay in response from us.

Are you able to use the xdsdfu utility to identify and run different commands on the XDS110 device of your board (i.e. enumerate device info, switch to DFU mode, download firmware, etc.)? Please see section 3.7.3.2 Firmware Maintenance Utility - xdsdfu of the below doc:

http://www.ti.com/lit/sprui94

Try the commands and provide screenshots of your cmd window on this thread if you run into any issues.

Best,

Kevin

Hii Kevin,

I followed the steps. My system is unable to detect board as mentioned. My TMS320F280049C is working fine(I flashed it by SCI).

hii Kevin Allen18 

Is there any update for me?

Chirag,

Please look at this section in SPRUI94 that Kevin mentioned above; 3.7.3.2 Firmware Maintenance Utility - xdsdfu, specifically at the top of page 20 goes through the process of downloading new FW to the emulator.

Try this and see if your system can then see the emulator.

Best,

Matthew

Hii Matthew,

I have tried those steps but my system is unable to detect launchpad. Hence I cannot use/apply those commands on the launchpad. Anyway, can you help me to know the reason why firmware/bootloader on the probe is being corrupted? My two launchpads are already corrupted. Will this problem still happen if I will use a standalone XDS110 Debug probe kit?

I am planning to use 

http://www.ti.com/tool/TMDSEMU110-U.

Chirag,

Let's use this page http://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_xds110.html#troubleshooting to see if we can get the XDS110s to show back up.  There is some additional steps to verify that the driver is still intact, as well as a method to force the host device into its DFU mode.

I don't have a solid reason to tell you how both the on-board XDS110s got corrupted in this fashion; I will say that CCS will attempt to update the XDS110 if there is a newer version of FW available automatically.  I'm wondering if this is happening, without any screen warning, and there is a power loss to the LP this could cause this issue.

I beleive the standalone XDS110 is similar in terms of its internals, so I would like to see  if we can resurrect the on-board emulator with the above link.  

Best,

Matthew

Thanks, Matthew for support.

I will follow the steps and post the result.

Matthew,

I performed the above steps but couldn't resurrect LP.  After forcing it into DFU by connecting TDO to the ground, my LP is not detected by the machine. 

I have one more question, When I force the processor in DFU mode, I have an only USB connection to upload the bootloader. Is the processor is able to accept firmware by USB or it accepts through only JTAG. LP has a separate JTAG connector for the TIVA ARM processor.

Chirag,

It should accept programmation through the USB, can you confirm that you are connecting pad 6 of J10(on the back of the board) to ground.  This is TDO of of the TIVA device.

I'm going to request some folks from our emulation team take a look at this thread to see if there is another way to get the TIVA back to behaving as an XDS110 that I may be missing.

Best,

Matthew

Is it possible the DAP is locked out and the unlocking procedure is require? Can the DAP port be unlocked in CCS debug via XDS110 console as we can do for TM4C1294 MCU?

Hi,

If the Debug Probe can't be seen by the host, even after trying to run its ROM bootloader by shorting Pin 97 to GND, there is a very strong possibility the TM4C129 device or one of its surrounding circuits are damaged (xtal, power, etc.).

To be absolutely certain, you would need the pogo adapter to plug into J10 (under the board) and an external Debug Probe to try and observe the TM4C129 device status. 

One question is: why exactly the firmware was becoming corrupt? Are there any surrounding conditions that could be causing this such as ground loops, faulty USB ports or cables, power issues caused by external factors (plug-in boards or other accessories)? 

If any external system is tied to the board, I would start fully isolating the USB port by removing the jumpers JP1/2/3 and provide external power. 

If there are no external systems, I would focus on the connection between the board and the host. 

Hope this helps,

Rafael

Rafael,

I will work on your solution, using an external debug probe with a pogo adapter. 

Yes, I have connected extra circuitry and multiple power sources too. 

I think if  I will remove Jumper JP1/2/3 then I will not be able to use JTAG for debugging as it's needed to connect launchpad with the machine.

Hi,

The jumpers can be removed without loss of functionality, but you need to provide external power to the device side of the Launchpad.

Regards,

Rafael

desouza said:

If the Debug Probe can't be seen by the host, even after trying to run its ROM bootloader by shorting Pin 97 to GND, there is a very strong possibility the TM4C129 device or one of its surrounding circuits are damaged (xtal, power, etc.).

Oddly the TM4C1294NCPDT can at times act the very same way if we try to LM Flash firmware when the DAP or device is locked. It acts like the USB port is not connecting to windows low level ICDI DFU device driver. Yet LM Flash unlocking procedure tab somehow proceeds but fails to connect  XDS-100 to DFU via CCS7.1 debug console, as other MCU forum discovered.

I fail to see why any TI MCU would not keep consistent in the ICDI connection scheme. The JTAG port of F820049C should be no different than TM4C1294 or any other class MCU. 

Hii,

Jumper 10 on Launchpad has a different connection pattern than a normal 10 pin ARM JTAG connection. That means I can't directly use output of XDS110 10 pin connector output(need to change connection pattern). Am I right? 

I am attaching both images.

It looks like the JTAG header picture was taken from the bottom PCB layer, is only inverted. Typically you need to make sure XDS110 pin 1 red stripe is aligns to pin 1 of launch pad header. Pin 1 should be marked on the PCB and external JTAG often requires you to remove a resistor or pull specific ICDI input low for the JTAG header to pass into the target MCU and ICDI port enters high impedance state to target.

I seriously doubt the external JTAG results will be any different and you should first attempt the unlocking procedure from CCS debug. You first have to modify the projects debug properties to Not load the program into flash, causing an abort exception fault. That way the DAP typically will accept a connection via ICDI direct from CCS debug and you attempt to use the console procedure for unlocking the device.