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.

TMS320F2812: Communication Problem

Part Number: TMS320F2812


Hello,

When I trying to burn it with the Code Composer Studio software I have an error of communication [1015] " Device is not responding to the request ",When I trying to do Test Connection it's fail in tests:

1.Perform the standard path-length test on the JTAG IR and DR.

2.Perform the Integrity scan test on the JTAG IR.
3.Perform the Integrity scan test on the JTAG DR.

I made an electrical tests and found some results:

1. Clock test - I using with external oscillator to set to Xclock 30MHz ,I check the Xclock pin and the clock is ok.


2. Jtag route test - I check the route of the signals: Tck,Tdi ,Tdo,Tms from the connector of the emulator to the Dsp pins and found ok.


3. Reset test - using in oscilloscope I see Pulses on the Reset pin of the DSP it should be 3.3V constant.

What could be the problem?

Attached Test Connection Result and the Error 1015:

[Start: Texas Instruments XDS100v2 USB Debug Probe]

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\DROR~1.MOS\AppData\Local\TEXASI~1\
    CCS\ccs1220\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 'Nov 28 2022'.
The library build time was '16:30:46'.
The library package version is '9.10.0.00080'.
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 many-ones then many-zeros tested length was 2048 bits.
The many-zeros then many-ones tested length was -2016 bits.

The test for the JTAG DR bypass path-length failed.
The many-ones then many-zeros tested length was -2048 bits.
The many-zeros then many-ones tested length was 0 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.
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.

[End: Texas Instruments XDS100v2 USB Debug Probe]

Best Regards,

Dror

  • Hi,

    The pulse on the XRSn pin is expected. From your test connection log, it looks like TDO is stuck high, are you able to share the schematic for your JTAG signals? 

    Best Regards,

    Ben Collier

  • Hi Ben,

    Thank you for answer me.

    Attached the Jtag route in 3 pictures:

    pic 1: JTAG route 

    pic 2: JTAG route 1

    pic 3: JTAG route 2

    Another thing that I not mentioned is that in another board I succeeded to burn the DSP with no problem.

    There are no hardware differences between the to boards.

    Thank you for your help.

    Best Regards,

    Dror Moshe

     

  • Hi,

    I do not notice anything wrong with your schematic, maybe there is some incorrect component value on this board? For example, this behavior would be expected if any of the TDI, TMS, or TCK pullup resistors were actually much lower in value.

    If you have access to an oscilloscope, could you try probing TDO (yellow), TMS (purple), TCK (blue), and TRST (green) as shown below. The screenshot below was captured using the XDS100, and it was a single-capture triggered on the falling edge of TMS. Could you try doing the same and see if your probed signals look the same? 

    Best Regards,

    Ben Collier

  • Hi Ben,

    I don't received the signals tat you got. 

    Attached the picture from the oscilloscop.

    Best Regards,

    Dror 

  • Hi,

    It looks like something is going wrong with the CLK signal. It seems to have a DC offset, and it does not get to 3.3V. 

    Could you take a look at this page: https://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_xds_target_connection_guide.html#buffered-case

    For C193, they have a capacitance value of 8.2pF instead of 33nF. It seems like you are making something resembling a low pass filter on your TCK signal. Where did you physically probe the TCK signal? Was it close to the F2812 pin?

    Could you try changing the value of C193 or could you remove R250 or C193 so that there is no path to ground? I am curious if that will fix your TCK signal.

    Best Regards,

    Ben Collier

  • Hi Ben,

    You right the LPF was the problem.

    When I removed the resistor it's work.

    Now I have a new problem, the DSP doesn't work on first start-up.

    When I checked the suppliers voltages (5V,3.3V) and RESET I find out that in first startup there are pules on reset signal in 227Hz frequency.

    I saw in the forum that it's happened to someone else but he got it before burning and I got it even after.

    Attached the start conversion from the post

    .

  • Hi Dror,

    That is correct, it is expected for the reset signal to pulse due to watchdog resets. Just to confirm, testing connection in your target configuration file passes now? Could you share the error that you see when trying to flash the device? Also, you have not previously been able to flash this device, correct? As Hareesh mentions in that thread, it may be useful to put the device into SCI boot mode, which I believe should stop the watchdog resets. 

    Also, since you scoped your power pins, did all of the power supply voltages look ok? 

    Best Regards,

    Ben Collier

  • Hi Ben,

    I succeed to burn the Dsp and the connection with the CCS is good.

    My problem is that in the first Boot, when I connect the power to the board the DSP is not execute the boot (I know it because there is a buzzer that should work on the start when I don't hear it I no that something wrong) and is I disconnect the cable and put it back immediately it's work.

    The voltage supply looks ok and no different between first tome to second.

    We choose to boot from external flash

    Something else that I saw is in the first time boot there are pulses on the Reset pin in 227Hz frequency ,and in the second boot the Reset signal is clean.

    Thank you for your help.

    Best Regards,

    Dror Moshe

  • Hi Dror,

    I disconnect the cable

    When you say this, are you referring to the power cable? Are you connected with JTAG at this point? 

    I just want to make sure that I clearly understand your issue. When you power on the device, you are not booting to flash correctly and running your program? But when you power cycle the device, it starts to work?

    Best Regards,

    Ben Collier

  • Hi,

    I just want to make it clear.

    The JTAG programming problem is solved.

    Now I have a problem with BOOT.

    At first powerup there is no boot, and I noticed that the RESET line is resetting every 4.4ms (227Hz).

    After powering OFF and then immediately ON again the RESET line goes high , no reset occurs and the boot is successful.

  • Hi Dror,

    Are you able to share the schematic for your board? I am particularly interested in the circuit that you have on the reset pin. Also, can you please take an oscilloscope capture of your VDDIO, VDD, XRS, and XCLKOUT signals on power up? 

    Best Regards,

    Ben Collier

  • Hi Ben,

    Attached are the relevant schematic pages and a photo of the signals you are requesting.

     

    ED1019314_13_merged.pdf

    Best Regards,
    Dror Moshe
  • Hi Dror,

    Since the XRS pin is pulsing, it looks like this power-on was one of the times when the device did not successfully boot to flash. Can you take a oscilloscope capture of one of the times when the device does boot to flash correctly? 

    Best Regards,

    Ben Collier

  • Hi Ben,

    Attached photo of the signals  when the device does boot to flash correctly.

    Best Regards,

    Dror

  • Dror,

    When the device is failing to boot to flash, it looks like the device is having a hard time with issuing a watchdog reset as the reset signal is not making it all the way to ground.

    Could you check if the device will properly boot to flash if you manually pull XRSn low, then let it go high again? Pretty much I want to see if XRSn reset will let you get out of the bad state and boot to flash like the power-on reset.

    Best Regards,

    Ben Collier

  • Hi Ben,

    I did what you suggested to pull down the XRS manually and that rise it to high, and it didn't change anything.

    I will very appreciate if you have some more thing to check.

    Best Regards,

    Dror Moshe

  • Dror,

    Could you take oscilloscope shots of your XCLKIN signal in both cases as well? It looks like something is wrong with the XCLKOUT signal in the bad state. Also, am I understanding the time scale correctly as 10 milliseconds? So the XCLKOUT period is close to 70 milliseconds at power up? Does this frequency change after the device has been powered on for a while? 

    Best Regards,

    Ben Collier

  • Hi Ben,

    I have a problem to give you pictures from the first moment of the power up because there is debouncing on the lines which cuase trigger.

    If you looking on the pictures you will see the XCLOUT with different frequency in bad boot ,you can explain to me why?

    Bad boot 1:

    Bad boot 2:

    Good boot:

    and picture of XCLKIN:

    Best Regards,

    Dror

  • Hi Dror,

    Does your XCLKIN look the same during both the good and bad boots? 

    Also, I wonder what is causing the oscillation on your 3.3V rails, I will have to take another look at your schematic.

    Best Regards,

    Ben Collier

  • Hi Ben,

    Can we continue the conversation by mail?

    Best Regards,

    Dror

  • Dror,

    Sure, I have sent you a friend request so we can send private messages.

    Best Regards,

    Ben Collier