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.

TMS320F28335: Error Error-233 was suddenly reported when the program was burned. It was always normal to burn the program before. It is okay to burn other boards with this emulator .

Part Number: TMS320F28335

Hi Team,

There's an issue form the customer need your help:

Is this chip locked? 

Connection emulator error: 

first:

[Start: Texas Instruments XDS100v3 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\YANGZI~1\AppData\Local\TEXASI~1\
CCS\ccs1120\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 'jioserdesusbv3.dll'.
The library build date was 'Mar 17 2022'.
The library build time was '15:43:48'.
The library package version is '9.7.0.00213'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.

An error occurred while hard opening the controller.

-----[An error has occurred and this utility has aborted]--------------------

This error is generated by TI's USCIF driver or utilities.

The value is '-182' (0xffffff4a).
The title is 'SC_ERR_CTL_CBL_BREAK_NEAR'.

The explanation is:
The controller has detected a cable break that is near-to itself.
The user must connect the cable/pod to the controller.

[End: Texas Instruments XDS100v3 USB Debug Probe_0]

---------------------------------------------------

Second:

[Start: Texas Instruments XDS100v3 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\YANGZI~1\AppData\Local\TEXASI~1\
CCS\ccs1120\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 'jioserdesusbv3.dll'.
The library build date was 'Mar 17 2022'.
The library build time was '15:43:48'.
The library package version is '9.7.0.00213'.
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).

An error occurred while hard opening the controller.

-----[An error has occurred and this utility has aborted]--------------------

This error is generated by TI's USCIF driver or utilities.

The value is '-233' (0xffffff17).
The title is 'SC_ERR_PATH_BROKEN'.

The explanation is:
The JTAG IR and DR scan-paths cannot circulate bits, they may be broken.
An attempt to scan the JTAG scan-path has failed.
The target's JTAG scan-path appears to be broken
with a stuck-at-ones or stuck-at-zero fault.

[End: Texas Instruments XDS100v3 USB Debug Probe_0]

Could you help check this case ?Thanks.

Best Regards,

Ben

  • Hi Ben,

    I do not think that the source of your problem is a locked chip, as your 'Test Connection' would still be able to succeed. If the device was locked, you just would not be able to read the device memory. There are many different issues that could cause the errors that you posted. Could you share the schematic of your design? How is the debugger connected to the device? If you have long traces, have you tried lowering the TCK frequency?

    Best Regards,

    Ben Collier