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.

CCS/TMS320F28027F: Custom board JTAG connection break during debug

Part Number: TMS320F28027F


Tool/software: Code Composer Studio

Hi,

We are testing on custom board with F28027 and DRV 8323. When motor is powered(PWM OFF), board works fine and debug works as expected. 

in lab 2c, as soon as I start motor identification process, JTAG connection breaks and i get following error in ccs.

C28xx: Error: (Error -1135 @ 0x85DB) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 7.0.188.0)
C28xx: Unable to determine target status after 20 attempts
C28xx: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

One thing can be noted, this error occurs only when motor is powered. I ger same erroe while running lab 5b as well. 

I use xds100v2 modified from a launchpad. Earlier JTAG isolators were removed, but when problem persisted, i added isolator again and removed R8,R9,R10 from launchpad as they are used for pull down of TDO, TRST and GPIO34.

I have a 2.2k pull down for TRST. TDO and GPIO34 are connected with 2.2k pull up and 10k pull down (just like 820ohm pull up and 2.2k pull down on launchpad) to boot controller from flash on power reset.  

Board and debugger are connected by less than 10cm wires. Soldered from end to end, i hope issue is not with wires.

To solve this following things have been tried so far.

1.  Tried to give stable external 3.3v supply.

2. Reduced wire length, but no luck.

3. Tried changing USB cables, it did not work either.

Surprisingly board works sometimes and variables can be monitored in ccs, but most of the time it does not.

What can be possible cause of this issue?

  • Hi,

    Error -1135 is described below:

    http://software-dl.ti.com/ccs/esd/documents/ccsv7_debugging_jtag_connectivity_issues.html#c28x-the-debug-probe-reported-an-error  

    As per your description, it seems to me this is a signal integrity issue that is causing JTAG communications to collapse.

    My suspicion is that the power stage and/or the motor are either introducing noise on the JTAG path, increasing the GND level due to ground loops or causing the device to reset inadvertently. 

    One detail that is not entirely clear: does the system run correctly despite the JTAG error? If so, the flash programming was performed successfully. 

    If that is the case, you can try the following test: launch the debugger, which will flash the code to the device and run to main(). After that, at the Debug View you can highlight the core and disconnect from it (Ctrl+Alt+D), which will make it run freely. After the system reaches a steady state, highlight the same core on the Debug view and re-connect to it (Ctrl+Alt+C), and see if you can have a stable JTAG operation. This test helps isolate the source of the noise, which is most commonly caused by the transient state and its inrush currents.

    If you still can't connect reliably in steady state, then the problem is that the JTAG itself is being flooded with noise - either conducted (via GND or other paths) or irradiated (over the air, the PCB, etc.). Since you found out that an isolated JTAG connection still causes the problem, this indicates the influence of ground loops between the host and the board are negligible. 

    I copy below some references that may help further investigate this issue and I will inform the experts in the device forum that may have additional tips about this. 

    http://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_xds_target_connection_guide.html#single-device-non-buffered-configuration 

    https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/21354 

    Regards,

    Rafael

  • Hi Rafael,

    Thanks for your help, though it did not resolve my issue, but gave me a better workaround solution. I needed debug mostly to find motor parameters. I can start debug session, let motor get identified and then reconnect again to read identified parameters.

    Regards,
    Shubham