CCS with C6727

Grtns,

Considering no feedback so far, I need a direct contact to tools group to address this CCS3.3 specific.  Our Sale/FAE team have no useful options for us, and migrating to CCS4px likely out of the question for now, and no current floating point DSP in the C674x today can give us what the C6727 is doing in our product.

Regards,

The C6727 does not have realtime capabilities, and thus connect to a running target is not supported - every connect will cause the halt.  So when you say "break realtime" is the issue that in 3.1 you could hit connect then run and not miss any deadlines, but in 3.3 the connect takes longer and so you can't run in time?

Darian

Grtns,

Using CCS3p1, when connecting to the C6727 device, it poses ~1 uSec overhead on the running application.

Using the same under CCS3p3, when connecting to the C6727, it poses ~240 uSec overhead on the running application.

That being said, CCS3.3 connect in distructive way to the target, vs. CCS3.1.

It has nothing to do with the DSP.

Regards,

Could you explain what you mean by "overhead"? Are you saying it adds ~240 uS latency to your app?

Grtns,

When CCS connect to the device, it should read the device peripherals config regs as it halt the CPU, and act on their setup.  I think in the case of the CCS3.3, it is not doing so.  The timer is not placed according to its config, and as a result, anything timed in the RT out of it get off by the amount of time the CCS take.

It is not the case in CCS3.1 and CCS4.1.1, except we can not move to CCS4.x at this time in our product development.  The changes made in the CCS4.x will severely impact our RT source code architecture.

Regards,

I am a little unclear about the situation. Here is what I understood so far:

In CCS 3.1, when CCS connected to a running C6727, it would halt the CPU and read some device peripheral registers and perform some device initialization (set some timers, etc). In CCS 3.3, these actions are NOT being done. Hence the application is not meeting its real-time deadlines.

My question (assuming I am correct with my interpretation): In CCS 3.1, how were those registers being read and timers being initialized? I don't think CCS would do these actions automatically. Were those actions being done in the startup GEL file's OnTargetConnect() callback for the C6727? And if so, are they missing somehow in the GEL file used with 3.3?

Sorry for my confusion,

ki

Thanks for the chat. This is what I have captured in my notes. Please correct me if I am wrong:

Application running on C6727, using CCS to connect to the target (using a Blackhawk 560 LAN (using USB hookup) ). CCS will halt the CPU during the target connect. After target connect is done, execution is automatically resumed with a run free command (via GEL call from OnTargetConnect). Behavior differs a bit between 3.1 and 3.3:

CCS 3.1: After CPU halt, device peripheral registers are read by CCS (driver) and then CCS will perform initialization based on this information. Then the target continues execution (as described above). The overhead of this is ~1uS.

CCS 3.3: After CPU halt, it appears that the device peripheral registers are not being read, hence no initialization being done. Then the target continues execution (as described above). In addition, the overhead of all this is also much higher ~240uS.

ki

The target cannot be accessed via the debugger while it is free running.  You need to halt if first.  So instead of connecting and issuing a free run and halting at a later time, why don't you just let it run disconnected and then connect at that later time.  Is there code prior to the run free in the OnTargetConnect() that you need performed or something?

Darian

Grtns,

I disgree with you.  We got an application already downloaded and running outside the use of the EMU.  We need to connect the EMU gracefully and examine thing in it.  In CCS3.1 all is good and dandy.  Using CCS3.3, no good.

Rgrds,

I'm afraid I don't know of any way to get CCS 3.3 to act the way you would like.  If my suggestions won't help, then I would recommend continuing to use CCS 3.1 for those specific cases.

Regards,

Darian

Grtns,

I appreciate your attempt.  We can no longer obtain additional CCS3.1 seats to support us, and we have been advised that the whole CCS3.x support will cease at the end of 2010.

Rgrds,

Grtns,

Since there seem to be an absent migration path in here for anyone using CCS3.1/GC5.3.0/DSP-BIOS5.2.0 etc... supporting the C6727B, where can we purchase legacy CCS3.1 copies that support the device?

I have seen many posting going around where folks are saying move to the new C674x, and ditch the C6727.  That is not a sound business practice.

Rgrds,

I still don't quite understand what actions you require the active connection for before you are ready to halt.  However, another option that may work for you would be to connect, run or run free, and then re-initiate the boot up sequence.  I believe a run free should actually survive a power loss on that device (I don't have one available to confirm, but I'm fairly sure), so even if you need to do something that intrusive to reboot, a free run should let you remain connected.

Darian

Grtns,

At this junction, and with the response I got from the local FAE quoted below

"From what we can tell, the correct and sufficient answers were posted on the forum, as highlighted in the attached screen-shot that was already copied to you below.

 The TI DPD group does not have a plan to migrate the GC5322/C6727B support to any version of CCS other than the CCS 3.1 currently being used. Their emulator of choice is the SD USB510.

 That said, there is no reason that I know of that the BlackHawk emulator would have different timing characteristics when connecting to a running target, but that is not a parameter that we address with CCS and the C6727B. If your team has verified a difference, please let us know."

 I am moving on without a resolution to these issues.  I appreciate your attempts, though.

Rgrds,