• Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 3403 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Windows update made CCS5.3 unstable

turboscrew
Intellectual 955 points

Has anyone else experienced similar thing?

After the Windows updates (in the beginning of December - 64-bit Windows 7) the CCS5.3 has started jamming.

It seems that it happens quite often, but in seemingly random situations.

Sometimes just opening the "run"-menu hangs up the CCS. Sometimes loading the program goes fine, but opening a source file jams the CCS5.3

Sometimes the connection to the target is suddenly broken:

"ICEPICK_C: Error: (Error -2172 @ 0x0) Unable to communicate with the emulator. Confirm emulator configuration and connections, reset the emulator, and retry the operation. (Emulation package 5.0.872.0)"

Every now and then CCS5.3 works just fine.

CCS3.3 seems to be working fine.

Any idea what could cause this?

  • TI__Guru*** 130875 points

    Hello,

    it is hard to say what in the windows update/environment change may have caused this.  However one thing you can do is enable logging and send us any error logs or dump (.dmp) files generated.  This might help lead us in the correct direction.

    http://processors.wiki.ti.com/index.php/Troubleshooting_CCS

    Please keep us informed.

    Best Regards,
    Lisa

  • in reply to Lisa TI
    Intellectual 955 points

    First, I have both CCS 3.3 and CCS 5.3 installed, and my machine is connected to the target via USB560M JTAG + XDS560T trace pod.

    With CCS 3.3 I can take traces with no problems. It also gets up and running every time.

    That used to happen with CCS 5.3 too until this December. The CCS 5.3 begun getting stuck here and there (random places):

    Setting a breakpoint, connecting to target, opening a source file, once even during the splash-screen.

    When I get the emulator, pod and board powered and the SW up and try "Test Connection" I have started getting:

    [Start]

    Execute the command:

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

    [Result]


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

    C:\Users\jaa\AppData\Local\.TI\693494126\
        0\0\BrdDat\testBoard.dat

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

    This utility has selected a 560/2xx-class product.
    This utility will load the program 'bh560usbm.out'.
    The library build date was 'Oct  3 2012'.
    The library build time was '22:05:09'.
    The library package version is '5.0.872.0'.
    The library component version is '35.34.40.0'.
    The controller does use a programmable FPGA.
    The old VHDL code has a version number of '0' (0x00000000).
    The new VHDL code has a version number of '386336272' (0x17070610).
    The old client VHDL code has a version number of '386336272' (0x17070610).
    The new client VHDL code has a version number of '805765648' (0x30070210).
    The old server VHDL code has a version number of '4' (0x00000004).
    The new server VHDL code has a version number of '45' (0x0000002d).

    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 '-181' (0xffffff4b).
    The title is 'SC_ERR_CTL_NO_TRG_CLOCK'.

    The explanation is:
    The controller has detected a dead JTAG clock.
    The user must turn-on or connect the JTAG clock for the target.

    [End]

    It used to pass before.

    Trying Run/Reset/System Reset I get this onto the console window:

    C64XP: Failed Software Reset: Failed to reset PRSC module
    C64XP: Trouble Reading PC Register

    Here are the log files, except the old installation log. I can give that too if necessary.

    4454.CCS_5_3_eclipse.log

    5187.DbgSrvDmp.log

    The dump-file is not generated (and never has).

    My machine is running 64-bit Windows 7.

    Oh, and after failing with CCS 5.3, I could connect with CCS 3.3 without touching the HW (card, cables, etc).

    Just exited CCS 5.3 and started CCS 3.3.



  • in reply to turboscrew
    Intellectual 955 points

    A-ha, the communication problem and "Test Connection" failure was due to the change of "Board Data File".

    It was "auto generate", but it used to be "auto generate with extra config file" and also the extra config file path

    was cleared, when there should have been path to the file "xds560tracepod.cfg", like it used to be.

     

    Also run the "scf /scannow" to the windows 7 as suggested here:

    http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_update/latest-automatic-updates-for-windows-7/417e7ca1-3dda-414b-81fe-9ad069beff3b?page=2

    At least the machine become much faster (or much less slow). It seemed to fix the jamming issue.

    There still seems to be something funny, but I'm not sure that does it relate to: compiling, loading, running or something else.

     

  • in reply to turboscrew
    TI__Guru*** 130875 points

    Hi,

    very glad you seem to  have found the main problem.   I would recommend posting again once you are able to narrow down the odd behaviour a bit better should you still require assistance.

    All the best with development.

    Best Regards,
    Lisa

  • in reply to Lisa TI
    Intellectual 955 points

    The disk fix seemed to fix the CCS 5.3 jamming.

    No jamming since.

    However, looks like at least in some situations, using XDS569T trace pod causes trace control process to be left running after the CCS 5.3 is closed.

    It seems to eat about 11% of the processor time and needs to be killed from the task manager. I'm not sure if that happens only when trace is taken during the session.