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?
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
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 moduleC64XP: 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.
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.
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.
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.