TMS320F28069M: Can't connect through XDS100 emulator

Dave,

XDS110 is a completely different design from the XDS100, it does not use an FTDI chip.  

For XDS100v2 the -151 error usually means that the EEPROM is not programmed.  What does FTProg say for the Vendor ID and product ID?  Or is FTProg no longer working at all?

Regards,

John

Hi John,

Sorry for the late reply. There was an illness in my family, and I had to take a couple of extra days off. Needless to say, the memorial day weekend was kind of a bust. I hope yours went well (if you're from here in the US).

I couldn't find drivers for the XDS100, so I figured maybe the XDS110 would do. Anyway, FTProg has the following parameters for the USB chip:

Chip Type: FT2232H

Vendor ID: 0x0403

Product ID: 0x6010

Location ID: 0x131

EEPROM Type: 93C56 EEPROM

Thanks,

Dave

Dave,

Sorry to hear about the illness.  I am in Canada so no memorial day for me (just a more quiet day).

Looking at the values the PID and EEPROM type are wrong.  There is another thread here where another team member has the step by step instructions for this.

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1000024/tmdscncd28379d-tms320f28379d-programming/3701135#3701135

The template he was using for the EEPROM is here

https://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/files/XDS100v2.zip

Can you try that and see if it gets you further?

Regards,

John

Hi John,

Here's the result from FTProg. From all appearances it seems like it successfully programmed the EEPROM. It even says "Finished Programming", displays a serial number, etc...

When I try using Code Composer, though, I still have the Error -151 @0x0.

There's another complication, however. Yesterday, for some reason, whenever I attempted to start up Code Composer, I got this message:

I uninstalled ccs and reinstalled it, using a different workspace. When I launched ccs, I tried to find target configuration under the View menu, and it just wasn't there. I thought "well maybe it has to be in the original workspace to find the path to the target configuration file." So I switched the workspace back to the original folder and got the above message again. I would love to fix this by changing the workspace again, but I can't open ccs to do that. I just hope I don't have to uninstall and reinstall ccs again.

Thanks,

Dave

HI Dave,

It does not look like the EEPROM was successfully programmed with the values from the template. Did you explicitly apply the template before programming? Opening the template file simply opens the file for editing. The template must be explicitly applied to the device using the steps shown below:

Thanks

ki

Hi John,

Here's a screenshot after applying and programming. I saw the bit about applying the template in the thread that you sent, but couldn't find it - it's just a right click.

In Control Panel, the ports are located under "Texas Instruments Debug Probes" and are listed as

XDS 100 Class Auxiliary Port and XDS 100 Class Debug Port

Looks like I could use them, if I could get Code Composer working. Do you have any suggestions there (per the previous post)?

Thanks,

Dave

Yes, 

Dave Reagan said:

In Control Panel, the ports are located under "Texas Instruments Debug Probes" and are listed as

XDS 100 Class Auxiliary Port and XDS 100 Class Debug Port

Yes, now this looks better. Are you still getting the -151 error after this?

Dave,

The FTProg values look much better now.  I would expect CCS to be able to communicate with the FTDI chip now.  

You coud try cleaning the workspace to see if that will let you open the original one to find your targert configuration file

https://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_troubleshooting.html#clean-the-workspace-or-try-using-a-new-one

So you don't see "Target Configurations" on the VIew menu in CCS for your new workspace?

That is odd that should be visible if you are in either the CCS Edit or CCS Debug perspectives.  If you put your mouse over the icons at the top right does it say CCS Edit, CCS Debug or something else?

Regards,

John

Hi John & Ki,

I emptied the .metadata folder in my workspace and that seems to have cured the ccs problems. I can see target configuration - the whole list actually.

The -151 error is gone, only to be replaced with:

Here's the result of my attempt to test connection:

[Start: Texas Instruments XDS100v2 USB Debug Probe_0]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

[Result]


-----[Print the board config pathname(s)]------------------------------------

C:\Users\dreagan\AppData\Local\TEXASI~1\
    CCS\ccs1031\0\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 'jioserdesusb.dll'.
The library build date was 'Apr 29 2021'.
The library build time was '17:49:40'.
The library package version is '9.3.0.00058'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '4' (0x00000004).
The controller has an insertion length of '0' (0x00000000).
This utility will attempt to reset the controller.
This utility has successfully reset the controller.

-----[Print the reset-command hardware log-file]-----------------------------

The scan-path will be reset by toggling the JTAG TRST signal.
The controller is the FTDI FT2232 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for FTDI FT2232 features.
The controller cannot monitor the value on the EMU[0] pin.
The controller cannot monitor the value on the EMU[1] pin.
The controller cannot control the timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '0' (0x0000).

-----[The log-file for the JTAG TCLK output generated from the PLL]----------

There is no hardware for programming the JTAG TCLK frequency.

-----[Measure the source and frequency of the final JTAG TCLKR input]--------

There is no hardware for measuring the JTAG TCLK frequency.

-----[Perform the standard path-length test on the JTAG IR and DR]-----------

This path-length test uses blocks of 64 32-bit words.

The test for the JTAG IR instruction path-length failed.
The JTAG IR instruction scan-path is stuck-at-ones.

The test for the JTAG DR bypass path-length failed.
The JTAG DR bypass scan-path is stuck-at-ones.

-----[Perform the Integrity scan-test on the JTAG IR]------------------------

This test will use blocks of 64 32-bit words.
This test will be applied just once.

Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Test 2 Word 0: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 1: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 2: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 3: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 4: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 5: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 6: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 7: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
The details of the first 8 errors have been provided.
The utility will now report only the count of failed tests.
Scan tests: 2, skipped: 0, failed: 1
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 2
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 3
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 4
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 5
Some of the values were corrupted - 83.3 percent.

The JTAG IR Integrity scan-test has failed.

-----[Perform the Integrity scan-test on the JTAG DR]------------------------

This test will use blocks of 64 32-bit words.
This test will be applied just once.

Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Test 2 Word 0: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 1: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 2: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 3: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 4: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 5: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 6: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 7: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
The details of the first 8 errors have been provided.
The utility will now report only the count of failed tests.
Scan tests: 2, skipped: 0, failed: 1
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 2
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 3
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 4
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 5
Some of the values were corrupted - 83.3 percent.

The JTAG DR Integrity scan-test has failed.

Thanks,

Dave

Dave Reagan said:

The -151 error is gone,

That is good. It looks like the EEPROM is programmed successfully.

Dave Reagan said:

The test for the JTAG IR instruction path-length failed.
The JTAG IR instruction scan-path is stuck-at-ones.

The test for the JTAG DR bypass path-length failed.
The JTAG DR bypass scan-path is stuck-at-ones.

Looks like you also ran into the same issue as the user in the other thread after he programmed the EEPROM of his XDS100v2.

Please see this post for an explanation of the error:

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1000024/tmdscncd28379d-tms320f28379d-programming/3702297#3702297

The root cause in that case was in the schematic:

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1000024/tmdscncd28379d-tms320f28379d-programming/3709853#3709853

Thanks

ki

Hi Ki & John,

The thread you referred me to ends with

"there is an issue with the connection of the TDO pin across the isolation device. This would be consistent with the scan-test failure. If possible, remove the isolation device and short the TDO traces across the isolation boundary for debug."

I also have isolated the TDO signal, so this seems to be the identical problem. So I'm supposed to just bring the TDO line directly from the FT2232, which is referenced to USB ground, to the micro, which is referenced to circuit ground?

Thanks,

Dave

Hi Dave,

No, you would also need to connect the two grounds together which would of course eliminate the isolation. In that other thread, the goal was just to verify that the TDO connection was indeed the problem. Assuming this was indeed the issue, the problem would need to be fixed through a hardware spin.