C6000 project build after migrating from CCS v3.3 to CCS v4

Which DSP are you using?   From codegen version, I assume 6x, but which specific device? 

From BIOS perspective, we did not make many significant changes between 5.33.03 and 5.41.02 other than adding new devices and some minor bug fixes.

A few things to check:

(1) You can load and debug (and use RTA and ROV) the executable you built in CCSv3, in CCSv4 and vice-versa.   Might be good to verify that the .out file that gives 21% in CCSv3 gives same in CCSv4.  And that the opposite behavior is also true.  This will narrow it down to a build issue.   The target .out files will work in either version of CCS.

(2) Next thing I'd check would be the memory map in the .map files.   I would expect the memory maps to be very similar in these 2 builds.  Can you verify that they are roughly same?   Addresses might be different, but gross section placement (DDR vs SRAM, etc.) should be same.

(3) Next thing I'd compare would be the .gel files.  Many times the .gel file is used to program the PLL or some device clocks.  You should be able to configure CCSv4 to use the same .gel file that you use in CCSv3.   If the .out files in (1) both work in CCSv3, then I'd suspect a .gel file difference.

Regards,
-Karl-

Karl,

Thanks so much for your help.  This is very high priority for us as we will have to revert back to v3.3 if not resolved.  The device is a C6747.  It's actually an OMAP-L137 but we are not using the ARM core.

Karl Wechsler said:

(1) You can load and debug (and use RTA and ROV) the executable you built in CCSv3, in CCSv4 and vice-versa.   Might be good to verify that the .out file that gives 21% in CCSv3 gives same in CCSv4.  And that the opposite behavior is also true.  This will narrow it down to a build issue.   The target .out files will work in either version of CCS.

Here is a breakdown of the builds I tried:

build 1: cgtool 6.1.8; built in CCS v3.3; optimizations = -o0.

build2: cgtool 6.1.14; built in CCS v4.1; optimizations = -o0.

build3: cgtool 6.1.14; built in CCS v4.1; optimizations = -o2, -ms1.

Here are results when running these in CCS v4.1:

Build1 runs correctly, CPU load graph = NO DISPLAY (graph never updates), LOG_printfs = don't work (no messages display on the log screen).

Build2 does NOT run correctly, CPU load graph = NO DISPLAY, LOG_printfs = don't work.

Build3 runs correctly, CPU load graph = NO DISPLAY, LOG_printfs = works (messages display on the log screen).

Here is results when running these in CCS v3.3:

Build1 runs correctly, CPU load graph = 37%, LOG_printfs = works (messages display on the log screen).

Build2 does NOT run correctly, CPU load graph = 35%, LOG_printfs = works (messages display on the log screen).

Build3 runs correctly, CPU load graph = 21%, LOG_printfs = works (messages display on the log screen).

Here are my observations.  Maybe you can comment...

• CPU load graph is not as good in v4 as v3.3.  I have run projects where it works, but only when the load is < 5%
• In CCSv4, we have to use optimizations for the code to execute correctly.  In CCSv3.3 this is not needed.
• In CCSv3.3, when the code is not running correctly, the load graph is only 35%.  So this indicates it may not be a CPU loading problem.  But we still need to explain why we need optimizations to resolve the problem.

Karl Wechsler said:

(2) Next thing I'd check would be the memory map in the .map files.   I would expect the memory maps to be very similar in these 2 builds.  Can you verify that they are roughly same?   Addresses might be different, but gross section placement (DDR vs SRAM, etc.) should be same.

I compared the map files when the compiler settings were -o0.  It was as you said.  very similar in size (6.1.14 was a few hundred bytes smaller).  This code all runs in L2 memory.  Nothing resides in L3 or off-chip.

Karl Wechsler said:

(3) Next thing I'd compare would be the .gel files.  Many times the .gel file is used to program the PLL or some device clocks.  You should be able to configure CCSv4 to use the same .gel file that you use in CCSv3.   If the .out files in (1) both work in CCSv3, then I'd suspect a .gel file difference.

I did check the output freq (the OSCOUT pin on the C6747).  It was 297.5MHz, which is the correct PLL freq. the DSP is set to run at.  This was true for both versions of CCS.  So I don't think it's a GEL file issue.  But I can try swapping the GEL files if you think it's worthwhile.

When the code is not running correctly, I captured data being streamed into the DSP from the FPGA.  There are gaps in the data.  The DSP reads in N samples using  SIO_reclaim.  When a new buffer is ready, the TSK resumes with N samples from the SIO.  It process the data and goes back to pending on SIO_reclaim.  The gaps in the data come every N samples.  This is why I thought it was a loading issue.  The DSP wasn't processing the data and getting back to the SIO_reclaim fast enough.  But the 3rd bullet above kind of contradicts this - maybe?

thanks,

Mike

Mike --

I'm guessing that there must be something different about the configuration.   The libraries should be very similar between those releases.  The configuration tool generates 3 files -- <file>cfg.s62,  <file>cfg.h62 and <file>cfg.cmd.

Can you please make zip file with the 5.33 version of these files and the 5.41 version of these files and attach the .zip file to this page?   I will look at the differences and see if it helps narrow this down.  Please add the .tcf file to the .zip as well if you can.  I'd like to get to the bottom of this.

Thanks,
-Karl-

Hi Mike --

I reviewed the changes between BIOS 5.33.03 and BIOS 5.41.02 and I do not think this is a BIOS problem (I've been wrong before, but that's my current thought).

I think best next thing to do would be to try changing codegen version and see if that makes a difference.

Let's try to 'break' the example in your CCSv3 setup.

(1)  In CCSv3, rename 'C6000/cgtools' to 'cgtools,bak'.  And copy the 6.1.14 compiler back to CCSv3 from (C:\Program Files\Texas Instruments\ccsv4\tools\compiler\c6000).  Rebuild and see what happens.  Directory structure should be same.

(2)  If that works, then go and get the CCSv3 version of BIOS 5.41.02 and install it into CCSv3.  You can get the CCSv3 version of 5.41.02 at this link:

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/bios/dspbios/index.html

After you install this, you need to go to Help->Component manager and select this new version of BIOS.  Close and restart CCSv3 and rebuild.

The above should split the problem in half and then we can look further.

Are you rebuilding the PSP drivers as well?  Or are you using the prebuilt version of the drivers in both cases?   Would be good to use same exact version of other libraries for both experiments to limit the number of variables to codegen and BIOS.

Thanks,
-Karl-

Karl,

I will work on splitting the BIOS and codegen tools as you suggest.  For this project, we are using modified versions of PSP 01.20.  The problem seems worse when I tried PSP 01.30 (by worse I mean even using optimizations in CCSv4 couldn't get it to run correctly).  But I haven't looked too much into that yet.

I'm also working on getting the project to run on the omap-l137 evm and using test vector files stored on the SRAM.  This way it will run w/o PSP drivers (except the maybe PSC) on the EVM and I can zip the whole project to you for testing.  Will that help?

Mike

Karl Wechsler said:

Let's try to 'break' the example in your CCSv3 setup.

(1)  In CCSv3, rename 'C6000/cgtools' to 'cgtools,bak'.  And copy the 6.1.14 compiler back to CCSv3 from (C:\Program Files\Texas Instruments\ccsv4\tools\compiler\c6000).  Rebuild and see what happens.  Directory structure should be same.

This worked fine.  I compiled my project in CCS v3.3 with compiler version 6.1.14.  Ran pretty much the same (CPU load graph = 37%) as 6.1.8.  However, I did have to copy over 1 library file.  My project uses fastmath67x.lib.  This library is in the cgtools\lib folder of 6.1.8 but is NOT in this location in 6.1.14.  So I had to copy over the lib file and header file to the 6.1.14 folder location to get it to build.  Could this be part our problem?

I'll move onto step 2 (probably have results tomorrow).

Mike

Karl Wechsler said:

Let's try to 'break' the example in your CCSv3 setup.

(2)  If that works, then go and get the CCSv3 version of BIOS 5.41.02 and install it into CCSv3.  You can get the CCSv3 version of 5.41.02 at this link:

This "successfully" broke the CCSv3 build.  It shows the same incorrect execution as the build in CCS v4.  I compiled with 6.1.8 and 6.1.14.  Both had incorrect execution.  So I guess the conclusion is that BIOS 5.41.02 is the culprit.  What is the next step?  Is there a workaround?  Is there some known issue introduced in 5.41.02 that causes this?

thanks Karl!

Mike

I was afraid of this (since I'm in BIOS team and can't pass the buck ..)

I reviewed the code between both of these BIOS versions and changes were trivial, mostly related to new device support.

Can you please attach your .tcf file so I can take a closer look at which modules you are using?   Are you using the "PRD" module?  There was a change in PRD code but that's about the only major change other than new device support.

Another useful thing to try would be to disable RTDX just to get that variable out of the mix.   This will mean that CPU load graph won't work, but app should work.

You can do this by adding the following 2 lines to your .tcf file:

bios.HST.HOSTLINKTYPE = "NONE";
bios.RTDX.ENABLERTDX = 0;

Karl,

If you're on the BIOS team, it sounds like I'm talking with the right guy to solve my problem :-)

Attached is a zip file with the tcf files.  I used separate files for the builds, only because the relative referencing of .tci files wasn't the same.  You can compare and see they are the same.  Also included are the .tci files imported by the .tcf.

I'll try your RTDX suggestion later today and get back to you.

Mike

Karl Wechsler said:

Are you using the "PRD" module?  There was a change in PRD code but that's about the only major change other than new device support.

yes, we use PRD as a heartbeat interrupt to blink an LED and scan for changes in DIP switches.  I could try taking those out and re-running...

Karl Wechsler said:

Another useful thing to try would be to disable RTDX just to get that variable out of the mix.   This will mean that CPU load graph won't work, but app should work.

You can do this by adding the following 2 lines to your .tcf file:

bios.HST.HOSTLINKTYPE = "NONE";
bios.RTDX.ENABLERTDX = 0;

Tired it.  No change; it still did not execute correctly.

Mike

Thank you for your patience, Mike.  I am completely stumped. 

Would you be willing to try a couple more things?

(1)  Let's try to "fix" the CCSv3.3 + 5.41.02 setup.  

Can you save the original version of these libraries (they are in bios_5_41_02/packages/ti/bios/lib)

-lbios6747.a674        /* BIOS clock specific library */
-lbios.a674            /* DSP/BIOS support */

and replace them with the files from 5.33.03.   And then relink and run?

(2)  If that "fixes" things, can you try adding the 5.41.02 version of prd.s62 to your project and rebuilding?  You can grab it from the attached .zip and add it to your project.  You might have to rename the .s62 suffix to .asm.

If this doesn't resolve it, then I think I need a test case and/or webex where we can work together.   Let's see where we are after you try the above before I5353.prd.zip figure out how we can get in touch with each other on conf call without us putting our phone numbers on this forum.

Thanks again.  We will find it!

Regards,
-Karl-

Please do step (1) above 1 at a time.  You do not need to swap them as a pair.

Thanks!

Karl,

Using v5.33 of bios6747.a647 didn't fix the problem.  Neither did using just v5.33 of bios.a6747.  In fact, with v5.33 of bios.a6747, the code doesn't even reach main.  I tired both together it again code execution did not even reach main.

I also tried an additional step I mentioned in a previous post.  I copied all the source files to a new folder and created a new project.  This project was using the same processing algorithms but was built to run an a C6747 EVM.  So for the most part the PSP was not being used.  Test vectors stored on SDRAM were used in place of receiving it from McASP.  In this case, the code executed without problems. So this project was built in CCSv4.1 with bios 5.41.  I guess part of the problem is tied to the PSP?  Hope this can be of some help.

Let me know if there are some other things you want me to try.  I'll send  you a friend request so we can exchange phone #s to set up a webex meeting.  I have done this previous with another TI employee and it was very helpful.

thanks,

Mike

Hi,

urgent help required

I am working on integrating DSP Link with Win CE 6.0, I followed all the steps as mentioned in Installation Guide for DSP Ling.

I am facing repeated error U1073, I am resolving these errors by searching file in WINCE600 folder and copying it to the error directory....

Logs:

************************************************************************************

BUILD: [01:0000000358:PROGC ] Linking C:\WINCE600\platform\OMAPL138_AM18X\lib\ARMV4I\retail\usbfndrvr.lib
BUILD: [00:0000000374:PROGC ] Building LIB Pass in C:\WINCE600\PLATFORM\OMAPL138_AM18X\SRC\DRIVERS\USB\USBOTG\ directory.
BUILD: [01:0000000384:ERRORE] NMAKE :  U1073: don't know how to make 'C:\WINCE600\OSDesigns\OMAPL138_AM18X_SAMPLE\OMAPL138_AM18X_SAMPLE\Wince600\OMAPL138_AM18X_ARMV4I\cesysgen\oak\lib\ARMV4I\retail\defbuslib.lib'
BUILD: [01:0000000386:ERRORE] NMAKE.EXE TargetLibFiles  -i -c BUILDMSG=Stop.  BUILDROOT=C:\WINCE600\PLATFORM\OMAPL138_AM18X LINKONLY=1 NOPASS0=1 failed - rc = 2

***********************************************************************************

It is virtually inpossible to resolve all errors like this.

any suggestions....

thanks in advance

hemant