• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 52 subscribers
  • Views 760 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Migration from ccvs3.3 to ccvs4.0 : memory allocation & .hex file

Sus LBelso
Prodigy 110 points


Hello,

I have a question  in relation to the migration from cvss3.3 to cvss4.0 (v 4.1.3.00038) and the memory allocation.

 

I have migrated from cvss3.3 to cvss4.0 and I have moved from Xp to win7-64bytes (this information maybe irrelevant, but just in case).

 

On both cvss versions I am using the same .cmd file with the information of the memory configuration. Besides, some sections within each memory type are defined in the code.

 

I wish I could obtain in both cases the same .hex file, but that is not what I really obtain.

 

There is a part of information (of one memory section) that, using the cvss3.3, is at the beginning of the hex file and with the cvss4.0 is also in the hex file, but in a different place.

 

I need to have that chunk of information in the same area as it is when I used the cvss3.3.

 

I have compared the map files and although the sections are within the correspondent memory area, they are not located in the same order.

 

Any suggestion about how to obtain the same .hex file as the file obtained using cvss3.3??? I will thank any contribution.

 

Best regards,

 

 Sus


 pd.I am using ccsv4. C5509A and XDS510 USB plus.

  • 0
    TI__Guru**** 467111 points

    Hi Sus,

    It is most likely the fact that you are using a newer version of the compiler that explains the difference. Unless you explicitly told CCSv4 to use the same version of the compiler that 3.3 is using, it will use the version that v4 ships with.

  • 0 in reply to Ki
    Prodigy 110 points

    Hi Mr Lee!!

    I am using the same compiler version in both cases. I use Texas Instruments DSP/BIOS <5.41.03.17> and CodeGeneration Tools v.4.3.6.

    Analyzing the .hex code more in detail ( the memory areas division) , I have noticed the following difference:

    Considering in both map files the same contents, there are different memory areas such as :

      VECT , BOOT, DARAM,  SARAM .....             

    And within DARAM area different SECCTIONS

    .Sec1, .Sec2, .Sec3... all of them properly defined within the area (and the same in both compilers).

     

    * In the .hex file generated using ccsv3 the data  is located as follows:

     VECT, BOOT (no info), .Sec1 .Sec2 .Sec3 ... and finally .bios, .rtdx_text .sysinit.

    * And in .hex file generated using ccsv4 the data is located as follows:

    VECT .bios .rtdx_text .sysinit .Sec1 .Sec2 .Sec3 ....

     

    Is there any option to change the position within the hex file to obtain the same .hex file in both cases (the .hex file obtained with ccsv3.3) ????

     

    Besides, trying to find out the solution to the problem, I have observed that on the project compilation additional files are generated. Among there  ProjetName.s55, ProjectName.h55 and ProjectName.cmd are included.  In the ccsv3.3 I have them included in the project files but in  the migration they do not appear. Should I do something with them??? I already have another CmdFile.cmd within the information of my project memory division.

    Thanks in advance,

    Sus

     

  • 0 in reply to Sus LBelso
    TI__Guru**** 467111 points

    Sus LBelso said:
    I am using the same compiler version in both cases. I use Texas Instruments DSP/BIOS <5.41.03.17> and CodeGeneration Tools v.4.3.6.

    If you are using the same exact versions of the compiler and BIOS, then there should be no change in the output. Changing the CCS IDE itself should not make a difference. Check your build options and make sure that they are identical for both builds. Did you use the project migration wizard to convert you v3 pjt to v4

    Sus LBelso said:
    Besides, trying to find out the solution to the problem, I have observed that on the project compilation additional files are generated. Among there  ProjetName.s55, ProjectName.h55 and ProjectName.cmd are included.  In the ccsv3.3 I have them included in the project files but in  the migration they do not appear. Should I do something with them???

    ?

    Those are generated files from BIOS. When you do a build, they should get generated. They may get generated in a different location (try looking in the configuration subfolder)

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 110 points

    Hello again ki,

    Yes, I migrated using the wizard and I have those files generated in a subfolder but, I do not have them included in the project.

    I have tried to add them in the project but there are plenty of errors linking... there are many errors indicating that some global variables are twice defined.

    I have also verified  a couple of times the build options and I consider them similar (cssv3.3 is runing over windows Xp and cssv4.0 over Win7 and I have no chance to install the cssv4.0 in the same laptop as the cssv3.3 is running).

    Thanks,

    Sus

  • 0 in reply to Sus LBelso
    TI__Guru**** 467111 points

    Sus LBelso said:
    I have tried to add them in the project but there are plenty of errors linking... there are many errors indicating that some global variables are twice defined.

    For migrated BIOS projects, you may have to edit your *.cmd file and remove the line that pulls in the BIOS cmd file. In v4 this file is automatically pulled so if you have it defined elsewhere, you'll get the "twice defined" error.

    But it still does not explain your hex file diff issue? Could you provide both files to me? You can send it via private message.

     

  • 0 in reply to Ki
    Prodigy 110 points

    Hello Ki,

    Thank you very much for your interest. I have solved the quiz.

    I include a brief summary of the problem and its solution. Maybe it  can be interesting for somebody else in the future.

    My problem is that I could not obtain the same .hex file using ccsv3.3 and ccsv4.0.

    I have 2 cmd files with the memory information areas. One is created at compilation (ProgramMap.cmd) and the other one is defined by me in the project (MyProgramMap.cmd). Memory areas are not overlaped among both files.  I wanted to obtain the same .hex file (the memory areas in the hex file in the same order) using both versions 3.3 and 4.0 but I observed  they were swapped.

    The differences:

    In ccsv3.3 both cmd files are added in the project and besides in Properties>>CCSbuild >>Link Order they are in the following order

                                                                                                                                                                                                                                             MyProgramMap.cmd

                                                                                                                                                                                                                                              ProgramMap.cmd

    In ccsv4.0 the files in a the program folder are associated to it and they do not need to be explicity included. A reference to MyProgramMap.cmd can be included in the Link Order. Nevertheless the ProgramMap.cmd cannot because the system does not create it in the program root. If the file is moved to the program root, an error indicating that information was duplicated appeared on linking (the same file was copied in the root and generated in its folder). The solution to obtain the same .hex file as it was obtained using the ccvs3.3 is to set in Properties>> CCSbuild > Link Order the following references.

                                                                                                                                                                                                                                 MyProgramMap.cmd

                                                                                                                                                                                                                                 Generated Linker Command Files

    Thanks again.

    Sus