• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 82 subscribers
  • Views 625 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CCSTUDIO3: CCS Scripting Utility automation help - CCS v3.3.83.20 with Visual Basic (VS 2019) in Windows 10

Akhil
Prodigy 20 points
Part Number: CCSTUDIO3
Other Parts Discussed in Thread: TMS320F2812

Hello all,

I am presently trying to re-establish a software testing environment for one of our legacy programs and have an issue using CCS Scripting Utility automation with Visual Basic.

The test environment is as follows:
- Windows 10 64-bit
- Visual Studio 2019 with .NET Framework 4.0 / 3.5
- CCS v3.3.83.20 (legacy tool used for TMS320F2812 DSP)
- XDS510 USB Debugger with Spectrum Digital 64-bit drivers
- Test procedure written in VB which interfaces to CCS using CCS Scripting Utility 1.5

The original environment consisted of WinXP 32-bit, Visual Basic 2008, .Net Framework 3.5, CCS v3.3.38. Because of some project constraints we could only upgrade to CCS v3.3.83.20. Everything works fine when directly working with CCS v3.3.38 GUI.

The problem I face is that some commands used in the original CCS Scripting Utility interface written in VB does not return after the execution. For example when I execute BreakpointSetAddress() it never returns. When I stop execution and check directly in CCS GUI, I can see that the expected breakpoint is set. Similar behaviour is seen with other commands like SymbolLoad(). Some other commands like CCSOpen(), TargetConnect(), TargetRunAsynch() etc. runs just fine.

Has anyone faced a similar situation or has any suggestions? The tools were installed from an admin account and I am also running it with an elevated privillege account provided by our IT dept. I tried the search forum option but could not find any similar issued raised before.

Appreciate any help. Thanks!

  • 0
    TI__Guru**** 472461 points

    Hello,

    Akhil said:
    The original environment consisted of WinXP 32-bit, Visual Basic 2008, .Net Framework 3.5, CCS v3.3.38. Because of some project constraints we could only upgrade to CCS v3.3.83.20. Everything works fine when directly working with CCS v3.3.38 GUI.

    You mentioned that everything works fine when working with CCS 3.3.38 GUI. Does everything also work fine with CCS 3.3.83.20 GUI (no scripting)?

    Please note that CCS 3.3 was never officially supported on Windows 10. The last version it was officially supported on was Windows XP. If you had a working environment on Windows XP in the past, I would strongly recommend going back to a Windows XP machine (native or VM).

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 20 points

    Unfortunately I forgot to mention that a part of the test env is built in LabVIEW. The whole system runs in an NI Teststand. NI does not recommend using virtual machine, and we use 64 bit LabVIEW anyway which cannot run in Win XP.

    We are now planning to change to Lauterbach debugger since they are our regular vendor and have a probe for the TMS320, with better driver support. I am trying to find a way to create an interface to automate the debugging with Visual Basic and hoping for better success here :-)

    Thanks for the support!

  • 0 in reply to Akhil
    TI__Guru**** 472461 points

    Do you need to use VB? Later versions of CCS have a more robust scripting environment. The old CCScripting Utility was very limited.

  • 0 in reply to Ki
    Prodigy 20 points

    Yes unfortunately. We have hundreds of legacy test scripts in VB which we do not want to modify for time and cost reasons. Therefore the old env has to be reproduced in Windows 10.

    I already tried to move to DSS scripting with newer CCS, but the Spectrum Digital drivers for CCS 4 and above I downloaded from http://spectrumdigital.com/spectrum-digital-inc/docsdrivers/ seems to be 16-bit. Therefore the decision to try Trace32.

    I already raised a ticket in spectrumdigital website about this but I doubt I will hear back from them. Do you happen to know anything about the SD drivers used for CCS v4 and above?

  • 0 in reply to Akhil
    TI__Guru**** 472461 points
    Akhil said:
    We have hundreds of legacy test scripts in VB which we do not want to modify for time and cost reasons. Therefore the old env has to be reproduced in Windows 10.

    Yes I understand. That makes sense

    Akhil said:
    I already tried to move to DSS scripting with newer CCS, but the Spectrum Digital drivers for CCS 4 and above I downloaded from http://spectrumdigital.com/spectrum-digital-inc/docsdrivers/ seems to be 16-bit.

    I thought CCS Eclipse SD drivers were 32-bit until CCS 8.3.1. CCS 9 and greater requires 64-bit drivers and the XDS510 drivers for CCS Eclipse was never updated to support 64-bit so there is no XDS510 support in CCS 9+.

    Akhil said:
    I already raised a ticket in spectrumdigital website about this but I doubt I will hear back from them. Do you happen to know anything about the SD drivers used for CCS v4 and above?

    Unfortunately SD is no longer in business so you will not hear back from them.

    ki

  • 0 in reply to Ki
    Prodigy 20 points

    I have an update - I tried to follow the method metioned in this thread to update to latest SD driver via device manager, and figured that I already have the Driver Version: 6.0.999.2 mentioned in that thread which works with new CCS versions.

    I only knew that our tools mananger installed the drivers for CCS v3 (CCS_3.3.83.20_Platinum) from SD website so not sure if this was an automatic update or something else. Nevertheless I could now choose the XDS510USB debugger for TMS320 and test connection succesfully from CCS v8.

    I am keeping the Lauterbach solution on hold for the moment. I will first try to adapt the existing interface from the test procedures to CCS Scripting utility to use the DSS instead. I see that there are no DSS APIs direcly offered for VB .NET anymore. My understanding from reading materials is that DSS supports Python/Jscript/TCL etc. The VB + ironpython route looks twisted, and I am now trying to see if I can integrate Jscript or Javascript to VB and then call DSS APIs. Another idea is to make a C++ DLL using TCL to call the APIs and then use this DLL with VB .NET. 

    I first want to ask if you (or anyone) have any concrete idea how DSS can be called from VB .NET so that I do not need to reinvent the wheel. This is my first time with Windows application programming and very short on experience here. 

    Thank you!

  • 0 in reply to Akhil
    TI__Guru**** 472461 points

    Good to hear that you are experimenting with a more recent CCS version and DSS scripting. 

    DSS is basically a set of Java APIs to the debugger. As you surmised, If you can find a way to have VB interact with Java APIs, then that could work. I have never tried this myself however. Hopefully someone on this forum has tried and can chime in

    Thanks

    ki