TMS320C6416: Windows 10 compatible CCS version that would work with TMS320C6416

Hello,

The latest, say, "good" CCS for C6416 was CCS v3.3. With some tricks it can be used on Windows7 machine. To my knowledge, no way to use it on Windows 10 though. Solutions split in two major paths.

If one want to have real time debugging, consider running CCSv3.3 in virtual machine. If you have emulator like SD 510 USB, it can be attached to virtual machine and perform load and debug. Avoid MS virtual machines though. VMware and Virtualbox both work perfectly.

The second option may be restricted by multiple conditions. Say, in similar situation we have an application been developed long time ago with DSP/BIOS rather than SYSBIOS. There is 5.42 version of DSP/BIOS, which can work with Eclipse based CCS. That legacy application may require older compiler like v.6x. One can install it in modern CCS. However, there will be no realtime debug support, only stop-mode debugging.

Though second approach looks like less burden, in my situation realtime debugging was a key requirement, so we use virtual machines.

Hope this helps.

Danilo,

It is a bit of a tricky question to answer without knowing more about what the customer is using.  As rrlagic pointed out there are other things like DSP/BIOS vs SYS/BIOS, the type of debug probe used... that would impact the choice of CCS version.  

The latest CCSv10.2 supports C6416 and runs on Windows 10.

Now come all the *

• If you are using an XDS510 class debug probe, which includes the ones that were built onto the C6416 DSK boards then the last version of CCS to support that was 8.3.1.
• If the application is using DSP/BIOS and is leveraging RTDX then support for using RTDX to have a real-time execution graph in CCS was really last supported in CCSv3.3.
• Much of the supporting software (CSL, board support library) would all have been build with CCSv3.x.

Thus many people open to just use CCSv3.3 as it was created in the same era as the device.  To use that on Windows 10 you are going to be looking at setting up a virtual environment.

What was the "compilation" issues that the customer was seeing?

Regards,

John

rrlagic/JohnS 

On win7 we were using the xds560 probe. We purchased a v2 of the same model (usb version). We are not sure what the RTDX execution graph is so we should be fine without that functionality. What it may sound like is that we would be able to build/load code using CCSv10.2, but maybe without real time debugging? 

If they are using CCS projects for building then they will need to migrate those to the newer CCS.  There are some considerations there:

1) Are they using DSP/BIOS or SYS/BIOS?  Those had their own "build" tool that may cause some issues.  i.e. if their project has a .cdb file in it then they are likely going to need to move to a newer version of DSP/BIOS like the 5.42 that rrlagic mentioned.

2) The compiler we include in CCSv10.2 is much newer.  You have the option of using an older compiler in CCS and that might be the way to start.

Moving a really old project to a much newer CCS is going to involve some work.  So it really depends how much work they are planning on doing.  If they are doing significant new development then investing the time to move to newer tools makes sense.  If they are just planning on some minor maintenance then I would look at setting up a virtual environment with CCSv3.3.

Regards,
John

Hello!

On https://www.ti.com/tool/TMDSEMU560V2STM-U#supported-products page I see your device among supported, so at least you should be able to load your program for execution.

One thing particularly useful is LOG_printf functionality of BIOS. We use it extensively to print program status, events and alike. These messages come with practically no impact to realtime execution of the application. So, say, when we have wireless terminal emulator implemented with TI processor, and connected with wireless DUT, we perform their signalling operation uninterrupted and still see what happens in application.

You will have no such a thing for your setup. DSP/BIOS, which provides LOG_printf(), uses RTDX for that. In turn, RTDX is not supported with Eclipse based CCSs. To see logs you'll have to halt the target, so called stop-mode debugging. Its up to you to decide, whether that is okay.

Let me share piece of my experience. We have DSP/BIOS project which has been developed last time with CCS v3.3. We used as XDS510, so XDS560 emulators to debug it in hardware. As CCS v3.3 becomes trickier and trickier to operate on newer version of Windows, we were keeping old PC as a reference machine and rest of development went in virtual environment. USB type emulators can be attached to virtual environment, so that works perfectly for us. I am still using Spectrum Digital XDS510USB.

We have some inconvenience of pretty long compilation/optimization time on CCS v3.3, so I've tried to setup copy of this project on Eclipse based CCS. I have manually installed DSP/BIOS v5.42, C6000 compiler v6.0.31. However, v3.3 project migration using CCS migration tool was not perfect, so I had to edit lot of thing in newly imported project. Somehow I've got it building and even managed to load target using emulator. And since Eclipse can run multiple build jobs, on my i7 with 8 threads build completes much faster. I've setup this Eclipse based project in a way, that object files reside same place as for CCS v3.3, and my older IDE does not need to rebuild them. So, once again, that is hard, but doable. However, for the reasons mentioned above, I still return to virtual machine when it's time to debug the application.

Victor Kazmirenko said:

In turn, RTDX is not supported with Eclipse based CCSs. To see logs you'll have to halt the target, so called stop-mode debugging. Its up to you to decide, whether that is okay.

Just to clarify, even stop-mode BIOS RTA is no longer supported in CCSv6 and beyond.

Thank you all for the input. Sounds like we wont be able to create new builds/debug without running through a virtual machine.