I have a project which was created in CCS Ver.2.20.03. I was using DSP/BIOS Ver.4.82.50 and CG tools Ver.4.32 and the binary generated from this build environment is working fine on my target(C6415).
Now i have to migrate the same project to higher versions of CCS. I am now trying to migrate to CCS Ver.3.3.38.2 (Integrated Development Ver. 5.98.0.219,BIOS Ver 5.31.02 and CG Tools v6.0.8).
When i open the project in CCS Ver.3.3.38.2, a Project Update (--version ID:5.1.8) POP-UP window comes and It will ask the following:
"IMPORTANT!
The project you are opening is based upon an older CDB configuration file. It must be converted to the new TConf Script (TCF) format if you want to edit the configuration and build the project.
Do you want to convert the project now?"
On clicking "Yes", a DOS window comes up and It will tell:
"Running "D:\MyProjects\PJTCCS3.3\cdb2tcf.bat"
Please wait...
cdb2tcf command SUCCESSFULL.
Press any Key to continue..."
On pressing any key, The Project Update POP Window again comes and it will now tell that:
"Conversion of the CDB Configuration file to TCF format successful.
The project has been updated, and a backup copy of the original project created.
Note: a generated CSL file has been added to your project.
You will need to add a call to clsCfgInit() manually to your main() function."
I have called CSL_init() followed by cslCfgInit() from my application's main() function after including the generated csl header file( contains the extern declaration to EMIFA and EMIFB config Structures) to this source file. I have also added csl6415.lib to the project.
The project, on building does not give any errors. But the generated binary is fails to load on the target. What could be the problem?
Is there something else i have to take care while migrating a project from CCS2.20 environment to CCS3.3 (the versions of cg tools,DSPBIOS are mentioned above)?
Shiras Pallikkara: The project, on building does not give any errors. But the generated binary is fails to load on the target. What could be the problem?
Could you provide more details on the failure message? Is it some sort of data verification error? invalid target? memory region is not writable?
i'm also having issues with this migration from v2.2 to v3.3
i'm also having problems getting my [project]cfg.s55 to compile.
It keeps bombing on "CLK_config" as though it is using the wrong include header file or something like that. My I should start my own thread.
Hi,
While loading the program, the progress bar goes up to an extent and will tell "Data Verification failed at address 0x81EAE7F0. Please verifiy target memory and memory map." On pressing OK to this POP up window, another POP up window will come and tell you "a Data Verification error occured,file load failed".
On looking in to the map file, i could find that 0x81EAE7F0 is the starting location of .cinit section and i have viewed the SDRAM memory from CCS. All the locations are having 0xFFFFFFFF. So i thought that EMIF registers are not properly initiallised for SDRAM and viewed those both EMIFA and EMIFB registers. These registers were not initialised to the correct values as is seen PRJcfg_csl.c. This is the file autogenerated while converting cdb to tcf and it has all the CSL configurations. CSL configuration is not supported in the BIOS version 5.31.02, which i am using in CCS3.3. But it was supported in BIOS Ver.4.82.50 which i was using in CCS2.20 and so my cdb filein this project had the CSL configurations as it is part of BIOS. When i wrote the correct EMIF configurations through CCS, and then loaded the program, it loaded correctly without errors.
Now, the CSL configurations are part of my application code (through CSL_init() and cslCfgInit() called in my main()) and my doubt is that how would the program load happens without the EMIF registers being initialised. I think the BIOS ver.4.82.50 configured the EMIF registers prior to loading the program. But i think such an option is not there in BIOS 5.31.02. How do i get EMIF registers configured before the loading DSP .out file?
Please see the attachments for screen shots of error messages.
Friends,
I maybe have solved my migration issues, so I offer you this idea, for what it's worth.
I was experiencing no errors in compiling or linking -- but the executable didn't run correctly. There was a visible difference in the map in terms of data storage allocation but I saw no problem with the difference.
The key difference between 2.2 and 3.3 is really not in the IDE version but in the code-building tools. What I was missing was a few .align directives in front of some of my data structures. It's easy to get lazy about this if it works -- as it used to, in v2.2. But when I thought about what I needed on boundaries and put those .aligns in there it started working again.
If you're doing unions to structs, or using native circular addressing you may need an align directive here and theer. I'm not sure what CLK_config is, but it seems possible that you're getting clobbered by something else because of an assumption you don't know you're making about array placement. Certainly, turn off any optimization and see if things move, then look at the map and see if you're straddling some important address.
Best wishes,
:) Robert
In my case, i have compared the map files from 2.2 and 3.3 and i see no significant differences.
I suspect the following:
In the CCS2.2, the BIOS version was 4.80 and in this, the CSL configuration which initialised the EMIF was part of BIOS. In CCS3.3, the BIOS version is 5.31 and in this, the CSL configuration has to be done by calling CSL_init and cslCfgInit() in my main function. So that means, the EMIF is configured in the application and not done before loading the program. I can load the program if i initialise the EMIF registers after connecting to the target through emulator, from the CCS through the the View->Registers option.
So my question is how i can initialise the EMIF registers prior to the loading the program so that i can avoid the SDRAM data verification error while loading? Can the User Init Function in the .tcf Global settings be used for the purpose? I mean, If i specify a function for initialising the EMIF registers as the User Init Function in BIOS configuration tool, will it help me to avoid data verification erro while loading?
Shiras,
You can initialize the EMIF in your GEL startup file (in the OnTargetConnect() callback). That is the common place for such initialization.
ki
Hi Ki,
I need a solution to initialise EMIF prior to loading the .out file, when target is not connected through the Emulator. GEL files can be used only when target is connected through emulator. I need a solution in real time situation. Is there option in DSP/BIOS to in initialise such registers prior to loading sections in the output file on to the devices connected to EMIF interfaces(in my case, SDRAM ic connected to EMIFA)?
Which boot mode do you use with your C6415? HPI, PCI, or CE1 ROM?
Whichever mode it is, you will need to write some initialization code that writes the proper values to the EMIF registers, and probably to other registers, to prepare the DSP to load the real code. This way this is done is different for the different boot modes that are available, but in all cases there will be some method available to do the same initialization as what is done in the GEL files.
Hi Randy,
I am using PCI boot mode for C6415.
Do you mean that i have to add some initialisation code in the application running on my host, to program the EMIF registers in DSP?
I have included the EMIF initialisation in my host application and still i am not able to get my .out file running.
My Project when built in CCS2.20 generates a .out file of size 1MB and this is working. The same project when built in CCS3.3 generates a .out file of 2.8MB and is not working.
In CCS2.20, I was using DSP/BIOS Ver.4.82.50 and CG tools Ver.4.32.
In CCS3.3, I am using DSP/BIOS Ver.5.33.06 and CG tools Ver.6.0.14.
Is this increase in size of .out file normal, when i upgrade BIOS and CG Tools?
What causes such an increase in output file size?
The debug symbol output generated by the CGT version that comes with CCS 2.2 is COFF format.
Later versions of the CGT generate DWARF output by default. DWARF contains much more information and the result is a larger out file due to the larger symbolic information.
This app note has more details...
Today, i could migrate my C6415 project from CCS2.2,BIOS 4.80,CGT 4.32 to CCS3.1,BIOS 4.90,CGT 6.0.8. The binary generated on built under the new environment is working fine on my target.
Then, i tried migrating this project(CCS3.1,BIOS4.90,CGT6.0.8) to CCS3.1,BIOS 5.20.05,CGT 6.0.8, having changed only the BIOS version. But this time, when i opened the project, it asked for CDB2TCF conversion and the conversion was successful and it generated one .c and .h file containing the CSL configuration contained in my old cdb file and i am told to call CSL_Init and cslCfgInit function from my main function. i am also told to include the CSL library (csl6415.lib) to my project. On the project build after these changes, i am not getting any errors. But the .out file is not working on my target. I havent modified anything in my source files except for the above changes for migration of BIOS from 4.90 to 5.20.05. As my project works fine under BIOS 4.90 with the same versions of CCS and CGT, iam sure that the migration to 5.20.05 is causing some problems to my .out file.
Should i do anything else other than the above, for migration from 4.90 to 5.20.05? Any changes in my application code is needed?
I have already referred to:
http://www-k.ext.ti.com/SRVS/CGI-BIN/WEBCGI.EXE/,/?St=27,E=0000000000006654954,K=7392,Sxi=8,Case=obj%2852425%29
and
http://tiexpressdsp.com/index.php/Migrating_from_BIOS_4.9_to_BIOS_5.x
Any clue on what could be the problem?
ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". TI AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY TI. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM TI.
Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.