TMS320F28388D: debug probe error

Hello,

Please refer to Table 1: Emulator Switch Selections in F2838x ControlCard User's Guide to ensure you're configuring S1:A correctly.

Best,

Matt 

I already referred and S1:A is connected appropriately. Still i have that issue.

Hello,

Are you using the on-chip debugger or an external debug probe? Also, a couple things to check:

1. Can you verify power is being properly delivered?
2. What does XRSn look like on power up?
3. Can you try putting the device in WAIT boot?

Best,

Matt

i am using the external debug probe.

I also checked all the power supply points in the control CARD docking station. power supply is fine. 
XRSn is active low at all the times.
The device is already in wait boot only.

Hello,

Jayasuriya T J said:

i am using the external debug probe.

Which external debugger are you using?

Jayasuriya T J said:

XDS100v2 USB Debug Probe_0/C28xx_CPU1

From the error message, it seems like your ccxml is configured for the XDS100v2. Please confirm this is correct.

Also, please verify if you're able to connect using the on-board XDS100v2. This could help rule out if its a debug probe or device issue.

Best,

Matt

I found out that is not the probe issue. I tried using another working probe. I still got the same error. 

Matt Kukucka said:

From the error message, it seems like your ccxml is configured for the XDS100v2. Please confirm this is correct.

This is correct.

Actually the control CARD i am using is TMDSCNCD28388D. In this, I am getting active low signal in both VDD and VDDIO pins even after powering on. Can we take this as the hardware issue? 

Hi,

Jayasuriya T J said:

In this, I am getting active low signal in both VDD and VDDIO pins even after powering on. Can we take this as the hardware issue? 

That may be the case. Can we check a few things to confirm that?

• Can you attach a picture of the controlCard setup along with the baseboard?
• Is D5 illuminated on the controlCard?
• Is a 5V supply provided on the baseboard with S1 appropriately configured?

Best,

Matt

Matt Kukucka said:

Can you attach a picture of the controlCard setup along with the baseboard?

Matt Kukucka said:

Is D5 illuminated on the controlCard?

yes

Matt Kukucka said:

Is a 5V supply provided on the baseboard with S1 appropriately configured?

yes

One more thing is XRSn pin is continuosly active low. So the controller is not able to come out of the reset state. Is that understanding rite?

Hello,

I'm able to connect with this setup, with S1:A position 1 and 2 both low and S2 configured for wait boot.

Jayasuriya T J said:

One more thing is XRSn pin is continuosly active low. So the controller is not able to come out of the reset state. Is that understanding rite?

Yes. If XRSn is always low, this can indicate that the internal Brown Out Reset (BOR) is being triggered due to a supply voltage issue or some issue on the board. 

Best,

Matt

Matt Kukucka said:

I'm able to connect with this setup, with S1:A position 1 and 2 both low and S2 configured for wait boot.

I also kept S1:A position 1 and 2 both low. S2:A postion 1 low and S2:A position 2 high. After this configuration, i tried to blink a LED using code from CCS. I got the following error.

Error connecting to the target:
(Error -2131 @ 0x0)
Unable to access device register. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK).
(Emulation package 9.12.0.00150)


And with this configuration JTAG DR integrity scan-test is also failing.

Actually i am just using the JTAG cable and i am using only the on-chip debugger. I mistakenly told i am using an external debug probe.

Hello,

Jayasuriya T J said:

Actually i am just using the JTAG cable and i am using only the on-chip debugger. I mistakenly told i am using an external debug probe.

If you're using the on-chip XDS100v2 debugger, you need to set S1:A position 1 high (ON). 

Best,

Matt

Matt Kukucka said:

If you're using the on-chip XDS100v2 debugger, you need to set S1:A position 1 high (ON). 

After this also, i am getting that 1135 error

Hello,

Can you try running a connection test in CCS? This can be found by opening your target configuration .ccxml.

Can you also try using a different power source? Perhaps a new USB cable or port. 

Best,

Matt

[Start: Texas Instruments XDS100v2 USB Debug Probe_0]

Matt Kukucka said:

Can you try running a connection test in CCS? This can be found by opening your target configuration .ccxml.

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\Suriya\AppData\Local\TEXASI~1\CCS\
ccs1240\0\0\BrdDat\testBoard.dat

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

This utility has selected a 100/110/510 class product.
This utility will load the adapter 'jioserdesusb.dll'.
The library build date was 'Jun 2 2023'.
The library build time was '12:47:07'.
The library package version is '9.12.0.00150'.
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 succeeded.
The JTAG IR instruction path-length is 6 bits.

The test for the JTAG DR bypass path-length succeeded.
The JTAG DR bypass path-length is 1 bits.

-----[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.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0
All of the values were scanned correctly.

The JTAG IR Integrity scan-test has succeeded.

-----[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.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0
All of the values were scanned correctly.

The JTAG DR Integrity scan-test has succeeded.

[End: Texas Instruments XDS100v2 USB Debug Probe_0]

Matt Kukucka said:

Can you also try using a different power source? Perhaps a new USB cable or port. 

after doing this also i got the same 1135 error.

Hello,

The test confirms that the JTAG hardware is correctly connected.

Given that XRSn, VDD, and VDDIO are always low (during wait boot), we can take this as a hardware issue with the board. 

Best,

Matt

Do you have suggestion regarding how this can be proceeded further?

Hello,

Matt Kukucka said:

Given that XRSn, VDD, and VDDIO are always low (during wait boot), we can take this as a hardware issue with the board. 

You will need to check for any shorts between the power rails and ground which could cause VDD/VDDIO to be always low. The schematic for the ControlCard are provided in C2000Ware: C2000Ware_6_00_01_00\boards\controlCARDs\TMDSCNCD28388D\Rev.B

Best,

Matt

I observed a short between GPIO0 and gnd. will that be the reason why we are getting that error?

Hello,

No, it shouldn't. It should only cause damage to that pin (GPIO0). Let me loop in the board expert to help debug the device.

Best,

Matt

Hi Jayasuriya,

There are many conflicting statements on this thread.

It was asked if you are using external debug probe. You mentioned yes, but the picture shows you are using the embedded probe on the control card, i.e. you have connected the USB cable to the control card. See Matt's picture of external debug probe for reference (black box labeled "XDS110 DEBUG").

You mentioned the power supply points on the control card were fine, but later said they were off. 

The test connection result shows a passing result "The JTAG DR Integrity scan-test has succeeded.", but also mentioned you are still seeing a connection error.

We need clear info to be able to provide assistance. 

Please share the latest picture of your setup. With a close up of the S1:A and S2 switch settings. Also please provide the status of the control card power supply pins and result of the "Test connection" test with this setup.

yeah. Initially i didn't know about external debug probe. So i mistakenly told that i am using that. So to confirm i am not using that black box which matt mentioned. 

and regarding power supply, initially in the control card docking station, wherever 5V and 3.3V is mentioned in those places i got the proper voltage when measured from the scope. But VDD (pin no 118) and VDDIO (pin no 119) pins are always low. 

The JTAG DR integrity scan-test is succeeded. But i am still getting the following error:
Texas Instruments XDS100v2 USB Debug Probe_0/C28xx_CPU1 Error connecting to the target: (Error -1135 @ 0x0) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 20.2.0.3536).
To resolve this problem only i need your help.


The setup diagram and S1, S2 connection is given below:

While debugging the LED blink code after giving the above connections i got the following error as mentioned in the picture:

The test connection results are as follows:

[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\Suriya\AppData\Local\TEXASI~1\CCS\
ccs1240\0\0\BrdDat\testBoard.dat

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

This utility has selected a 100/110/510 class product.
This utility will load the adapter 'jioserdesusb.dll'.
The library build date was 'Jun 2 2023'.
The library build time was '12:47:07'.
The library package version is '9.12.0.00150'.
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 succeeded.
The JTAG IR instruction path-length is 6 bits.

The test for the JTAG DR bypass path-length succeeded.
The JTAG DR bypass path-length is 1 bits.

-----[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.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0
All of the values were scanned correctly.

The JTAG IR Integrity scan-test has succeeded.

-----[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.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0
All of the values were scanned correctly.

The JTAG DR Integrity scan-test has succeeded.

[End: Texas Instruments XDS100v2 USB Debug Probe_0]

The fact that the test connection is passing suggests that the MCU on the controlCARD is in fact getting power. In your original picture you showed D5 LED (back of board) is on, which indicates the VDD_3V3 rail is turned on in the controlCARD. 

You can verify the MCU supplies by measuring the voltages on test points TP8 and TP9.

The only thing I can think of as to why the LED blink example fails to load and the JTAG integrity test passes is that you may be using one CCXML file to run the JTAG integrity test and different CCXML to load the LED blink example. In the LED blink CCS project folder, there should be a CCXML file. Please open that and run the JTAG integrity test. If that fails, then you can compare the Advanced settings of the CCXML that passes against the LED blink CCXML file. 

Between TP8 and TP10 i got 3.3V. Between TP9 and TP10 i got 1.2V when measured from the multimeter.

Gus Martinez said:

In the LED blink CCS project folder, there should be a CCXML file. Please open that and run the JTAG integrity test.

Exactly this is how i did the test.

Ok, good, so there is power on the controlCARD. We can rule out a hardware issue. 

Can you share a screen grab of your CCS window, including the target config folder in LED blink project? I want to confirm that the LED blink CCXML is setup as the "active" or "default" CCXML.

Thanks for the screen grab. That looks ok. Next steps:

- Please probe TP2 (XRSN): This signal should be high continuously after you power on the control card.

- Please probe TP6 (MCU clock): There should be a 20MHz clock signal here.