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 V5.2.0.00069 crashes on exit from debug. Leaves process running

Other Parts Discussed in Thread: CONTROLSUITE, CCSTUDIO

Win XP64

I'm going through the example programs for the F28069 ControlStick using the controlsuite projects. Projects load (example FIR32, IIR2p2z), compile, and run. When I halt and hit the red button to return to the source screen, CCS5 freezes. I have to use the task manager to close it. Process "CCSTUDIO.exe" is left running and can't be deleted so CCS can't be openned again (error message: "Workspace is in use or can not be created...".

All other programs running are running normally. However, software re-boot of the system is somehow disabled. I have to cycle power to re-boot the system.

  • Hi Andy,

    What version of CCS are you using?  Do you see this with all projects/workspaces?   Have you tried renaming ctools.dll?  (could you give this a try)

    Do you get any .dmp files or error logs generated upon crashing?

    Best Regards,

    Lisa

  • Hi Lisa,

    The version is V5.2.0.00069. I haven't tried renaming ctools.dll. Why would I do that?

    Here is some more info. Windows soft reboot does eventually work. It took 3 miutes.

    When CCS is locked up, it comes back if I unplug the controlstick. I then have to exit CCS and plug the stick back in before re-invoking CCS. If CCS is running when I plug the control stick in, it doesn't find it. I'm using the XDS100 driver.

  • Sorry, I didn't answer your questions, Lisa.

    Renaming ctools.dll has no effect.

    Yes, it acts this way with different workspaces but only with the control stick. It works fine with the MSPFET-430.

    Where would I find dump files or error logs. I'll take a look.

    Andy

  • Hi Andy,

    There is information about the error and such logs here.  

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

    I am going to see what we can do next and speak with some colleagues.  I think I have noticed a couple other people with similar issues.

    Best Regards,

    Lisa

  • I followed the instructions to set CCS to generate logs. It didn't generate any for this error, or if it did, it didn't save them.

    Andy

  • Hi Andy,

    in your device manager do you see anything that could indicate an issue?  I wonder if there is a problem with the FTDI drivers.

    Have you tried installing these stand alone?  Have a look here ..

    http://www.ftdichip.com/Drivers/D2XX.htm

    Please keep us informed.

    Best Regards,

    Lisa

  • I think I re-loaded the FTDI driver. Replacing it with the FTDI download did not work. I uninstalled all three devices (Composite, A, and B). The manual driver installer couldn't find any drivers in the folder I unzipped from FTDI. When I plugged the ControlStick back in, it auto loaded a driver from somewhere and the Composite, A, and B USB devices appeared back in the device list as expected.

    Here is the new behavior. Hitting the RED button to exit debug mode still causes CCS to hang. It doesn't matter if I "run" or not. Pulling the ControlStick during the hang causes the exit to proceed successfully. Plugging the ControlStick back in now works (new behaviour) without error so that the process can be repeated without having to exit CCS.

    Andy

  • Andy,

    Would you be able to gather these two pieces of information to help me investigate?

    • In the Help -> CCS Support dialog, enable Debug Server Logging and specify a file to log to. Re-create the problem, and post the generate log file here.
    • A quick way for me to check the versions of all the DLLs that are being loaded is through the crash dump file. This allows me to verify there is nothing obviously out of place being loaded into the process space. As your application isn't exiting in a way that would create one, we can force one to be generated by faking a crash. Could you start a debug session and connect to your target. In the expressions view, please enter "DEBUG_Kaboom()". This will force an internal exception in CCS and cause it to create a crash dump file and exit. When you start CCS the next time, please go the help -> CCS Support menu, select the "Debug Server Dump files" item, and click "view". Attach any files you find in the folder here.
  • Done. The 2 files are attached.

    Thanks

    DebugServerFiles20120709202451.zip
  • Andy

    The crash dump log looks completely normal.

    The debug server log shows that shutting down the emulation connection is taking forever so there would seem to be an issue with connectivity to the emulator and this is perhaps causing the process to stick around. Have you selected XDS100v1 or XDS100v2 in the device setup editor?

    I wish I had something more helpful here.

  • It's set to V1. I couldn't figure out how to set it to V2 to try that. Setting up the target is non-trivial.

    Andy

  • I imported a PWM project from ControlSuite and tried every USB port (maybe it's a power issue?) and every appropriate target configuration (controlstick 28069), XDS100V1 and XDS100V2. Results are the same. RED button (end debug) freezes CCS (changing from XDS100V1 to V2 also freezes it and requires ControlStick unplug-re-plug).

    Just to be sure, I plugged in the MSP-FETU430IF with a target board and switched workspaces. It works perfectly.

    I'll try another computer tonight.

    Andy 

  • I connected the 28069 controlStick to my XP32 system with CCS V5.1 and ControlSuite (6 updates back). Imported a project, worked great. Then I went into update hell. I did the six updates to bring controlSuite up to date. The update from CCS V5.1 to 5.2 wouldn't work. It complained about not being able to find the 5.2.0018 update path. I think I read about that on the forum.

    While I had the new controlSuite example programs for the controlStick, I decided to load the BlinkLed project back into the stick using CCS 5.1. The build now reports "over lapping RAM segments" and failed to compile for both the flash and ram versions. Obviously there is an environment link between CCS versions and controlSuite example program versions.

    I decided to uninstall V5.1 and do a fresh install of 5.2. The uninstall, using the Windows control panel, hung. That's happenned before with CCS. I'm going to have to manually uninstall it and repair the registry. Maybe tonight....

  • Andy Nicoll said:

    I connected the 28069 controlStick to my XP32 system with CCS V5.1 and ControlSuite (6 updates back). Imported a project, worked great. Then I went into update hell. I did the six updates to bring controlSuite up to date. The update from CCS V5.1 to 5.2 wouldn't work. It complained about not being able to find the 5.2.0018 update path. I think I read about that on the forum.

    While I had the new controlSuite example programs for the controlStick, I decided to load the BlinkLed project back into the stick using CCS 5.1. The build now reports "over lapping RAM segments" and failed to compile for both the flash and ram versions. Obviously there is an environment link between CCS versions and controlSuite example program versions.

    I decided to uninstall V5.1 and do a fresh install of 5.2. The uninstall, using the Windows control panel, hung. That's happenned before with CCS. I'm going to have to manually uninstall it and repair the registry. Maybe tonight....

    The part about overlapping ram segments was fixed by right-click the Project name and "Refactor/Upgrade Compiler Version".

  • I wiped CCSV5 from my computer and the registry. Then I did a new download and install of V5.2.1.0018.

    Then I imported the "Timer - BlinkingLED" project from  \controlSUITE\development_kits\F28069 controlSTICK.

    I refactored to upgrade the compiler (be sure to click "Apply to all configurations"), then I built the RAM and FLASH configurations. For some reason, the RAM configuration must be manually set up in the properties/general dialog.

    Note: It auto populated the "Runtime support library" field in the RAM configuration with rts2800_mil.lib. That causes compile errors with references to 28027. I changed it to rts2800_fpu32.lib for both configurations and they both compile.

    Next time I'll let controlSUITE import it and see if that works any easier.

    Andy