CCS/TMS320C5545: Is the v8.1.x tools compatible with the c55x 4.4.1 CGT?

HI John,
C55x is still supported and tested... though likely more limited than some of the other more current devices. I will confirm when I get back to the office.

As for the issue you are seeing with 8.1, if you load a program built with CCSv5/6 into 8.1, does it work as expected?

Thanks
ki

Ki,

I've posted a project to Github - I think the best thing to do is for you to try and run it with the latest tools so you can see what's happening:

The URL is here:

Try to make sure the following is loaded:

EZDSP5535.ccxml and ezdsp5535.gel files in the debugger - you'll see what I'm talking about.

The project is for the eZdsp 'c5535 - hopefully you can locate one around there - I would imagine there would be one in the test/compatibility lab for the TI IDE and compilers.

Thanks,
John

URL - just in case:  github.com/.../eZdsp_DBG

Ki,

OK - that's interesting.

Can you please try these two workspaces:

eZdsp_DBG/->eZDSP_5535_Files->ccsws2

eZDSP->eZDSP_5535_Files->ccsws2

I can't get the debugger to start without doing almost everything manually - using the EZDSP5535.ccxml and ezdsp5535.gel files.

I had forgotten there were any other workspaces in that repository. But if you loaded them with no problem then I'll look at those also - but I need you to try the two above - with the emphasis on the first one.

Once you get past main and run; you have to press the switches on the eZdsp board a few times and then the LED's will all blink continuously.

The readme.md in the repository has instructions on which workspace to grab - I thought anyone trying this would grab those workspaces first.  

Thanks,
John

Ki,

Yes, auto run to main is what should happen per the settings in the debugger set-up file.

Can you run beyond that?  If you press SW1 and SW2, and run the demo, you should see the LEDs blink.

Does the debugger ever stop; requiring you to hit the run button again?

Also, when I load - I have to manually connect target and then I have to manually load the file.

How are you doing this with the v8.1 tools?  I can only get what you're talking about to work if going back to the v7.4.x tools using the xml and gel files that come with the eZdsp 5535.

The version 8.1 tools does not have a built in target for the eZdsp 5535 like in the version 7.4.x tools, so I'd like to know how you're doing that.

Thanks,
John

Yes, the demo appears to run. Eventually the debugger does stop, halted at vErrorChecks after all 4 LEDs are lit up in different colors.

How I am running the demo:

i am using the EZDSP5535.ccxml file in the project to start a manual debug session. I manually connect to the target and load the program.

CCS 8.1 has an EZDSP5535 option. I created one from scratch and use that one successfully also.

I tried the "Debug" button also. I noticed that the 'test' debug launch configuration has the option for auto-connect disabled. Is that intentional? The default for project based launch configurations is to have it enabled. If it was not intential, you may want to delete the launch config and let the debugger generate a new one.

Thanks

ki

In CCSv8.1.0:

From target configuration editor:

In project settings:

What are the options you see for both methods?

Thanks

ki

Ki,

OK - but I just tried to reproduce what you did and it isn't working for me - let me try again - then I'll post my screen shots.

We used to call this "works for you, not for me" - means obviously our set-ups aren't the same.

Thanks,
John

Ki,

EZDSP5535 does not show up for me.

So, why is happening?  Works for you, not for me.

Thanks,
John

I can probably explain why it is happening. I will bet that the ezdsp5535.xml file is missing in your CCSv8 installation directory. It *should* be in:

<CCSv8 INSTALL DIR>\ccsv8\ccs_base\common\targetdb\boards

Why is it missing for you? I am going to guess that since the board is from Spectrum Digital, you need to have the Spectrum Digital drivers installed, in addition to C5000 device support installed. I'm guessing you did the latter but not the former?

John Westmoreland43 said:

OK - I copied over the xml file from the 7.4.x install dir that I recently just reinstalled; plus the .gel file that was in the emulation directory, so now that's showing up as an option in v8.1. I wasn't 100% sure these files would be compatible with previous versions; but this is good to know.

I'm pretty sure that the xml file in question comes from the spectrum digital install package. But since the emulation driver being used is TI's XDS100, just copying the gel and xml file should be enough.

John Westmoreland43 said:

Otherwise we're seeing similar behavior in the debugger, I think that is due to maybe what I'm doing with DBSTAT, still not 100% sure about that - but at least we've got this far; and it explains why I thought I was seeing some differences.

"Otherwise we're seeing similar behavior in the debugger" - does that mean that the test example is halting for you at main now as it does for me?

John Westmoreland43 said:

I can start another thread - but there's an update for the c2000 tools that's been trying to install for a couple of days that fails - do you know anything about that - it's tried several times and has failed:

An error occurred while collecting items to be installed
session context was:(profile=epp.package.cpp, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=).
No repository found containing: org.eclipse.update.feature,com.ti.c2000.support.win32,4.2.5.0
No repository found containing: binary,com.ti.c2000.support.win32_root,4.2.5.0

Maybe there's a post about that already.

Did you see the section in the troubleshooting guide?

See #5 of the below link:

http://processors.wiki.ti.com/index.php/Troubleshooting_CCSv7#Update_features

Thanks

ki

Ki,

It's blurry where this question belongs. Since DBSTAT affects debugging; seems it's more appropriate in this forum since support for the 'c55x series regarding the CGT, etc. is or has been deprecated. I'd rather not move this question to where it'll be summarily ignored.

The CPU advisory question is related; no question; but has anyone answered it yet?

Also - I'm asking for valid DBSTAT values - which is a legitimate request.  And not the same question.

I know these values are valid;
0x001F  ; single-step or run?
0x005F  ; single-step or run?
but that's about it.

Can you please give me a list of valid values?

Anyone at this point that flippantly answers:  Don't touch it - has not actually done any actual debugging with the 'c55x family.  Look at Sysstack.  It can't
be ignored.  When returning from an ISR using the large memory model while in C54_STK mode; it must be set correctly.

I'm certain the DSP/BIOS tools set it - this will be a matter of looking at that and letting me know what the valid states are for DBSTAT.  Seems like that is a fairly simple request.

Also, it appears to me the devices forum has turned a bit nebulous since it's an aggregation of so many device families now.

Thanks,
John W.

John Westmoreland43 said:

It's blurry where this question belongs. Since DBSTAT affects debugging; seems it's more appropriate in this forum since support for the 'c55x series regarding the CGT, etc. is or has been deprecated. I'd rather not move this question to where it'll be summarily ignored.

The CPU advisory question is related; no question; but has anyone answered it yet?

The device forum is the best place to start regarding DBSTAT. Looks like the question was answered - CPU_119 has not been addressed and it appears there are no plans to address it. Hence any fix would have to come with a workaround in the debugger. I will file a bug for this.

As for the explanation of the DBSTAT values, I will forward this to the correct folks to answer.

Thanks

ki

The DBSTAT appears to be a typo in the document.  The register is DBGSTAT and has the following definitions in the CCS driver code:

#define DBGSTAT_ADDR ((TRG_ADDR)0x000800) /* DBGSTAT byte address */

#define DBGSTAT_IDLE_FLAG  ((UINT32)0x00008000) /* 15 1=Device in IDLE state*/
#define DBGSTAT_BRK        ((UINT32)0x00004000) /* 14 1=HW Break, STOPPED */
#define DBGSTAT_BRK_PEND   ((UINT32)0x00002000) /* 13 1=HW Break pending */
#define DBGSTAT_ANASTOP    ((UINT32)0x00001000) /* 12 1=Analysis, STOPPED */
#define DBGSTAT_ESTOP1     ((UINT32)0x00000800) /* 11 1=ESTOP1, STOPPED */
#define DBGSTAT_ESTOP0     ((UINT32)0x00000400) /* 10 1=ESTOP0, STOPPED */
#define DBGSTAT_HPI        ((UINT32)0x00000200) /* 9 HPI bit - see chap 6 */
#define DBGSTAT_IDS        ((UINT32)0x00000100) /* 8 IDS bit - see chap 6 */
#define DBGSTAT_EXSM_MASK  ((UINT32)0x000000C0) /* 7:6 EXSM State */
#define DBGSTAT_EXSM_IDBG  ((UINT32)0x000000C0) /* 7:6 IDBG */
#define DBGSTAT_EXSM_IDS   ((UINT32)0x00000080) /* 7:6 IDS */
#define DBGSTAT_EXSM_DSUSP ((UINT32)0x00000040) /* 7:6 DSUSP */
#define DBGSTAT_EXSM_EXE   ((UINT32)0x00000000) /* 7:6 EXE */
#define DBGSTAT_FXWOK      ((UINT32)0x00000020) /* 5 For CPU use only */
#define DBGSTAT_DFC_MASK   ((UINT32)0x0000001F) /* 4:0 Current DFC value */

Note that this is a memory mapped register.  It may be writable, but the driver only reads the register.  And the driver only examines the following bits: DBGSTAT_BRK, DBGSTAT_ANASTOP, DBGSTAT_ESTOP1, DBGSTAT_ESTOP0, and DFC_MASK. There appears to be no reason you need to set these bits. The driver is only using them to determine what event caused the core to halt and to retrieve the current debug frame.

Edward,

Please give me the memory mapped address of DBSTAT for the 'c55x family.

Thanks,

John W.

Edward,

I looked at this in the debugger - for the c55x family, the DBSTAT address is not 0x800.  

For the c2000 family, it appears to be correct - I verified that on one target - 0x800 on the TMS320F28069 appears to be DBGSTAT.

I ran two different targets for the c55x - didn't see any correlation there.

Can you please check that; I'm very interested to get the DBSTAT address for the c55x if that is actually memory mapped; which I've been told it was not.

Thanks,
John

Ah, looks like there is a difference between the C28x and C55x families. In the C28x, the register is mapped to the data page.  In the C55x, the register is mapped to the I/O page. But the address and bit definitions used in the two CCS drivers are the same.