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.

TMS320C6415: Problem with Migration of C6415 project from CCS2.21 to CCS3.3

Part Number: TMS320C6415
Other Parts Discussed in Thread: CCSTUDIO

We have a very old C6415 DSP project created in CCS2.21 that we want to migrate to a newer CCS version and toolset.  We have migrated the project through CCS3.3 and then to CCS8.1 to get to the latest tools and libraries.  This project builds, loads in a debugger and runs for the most part building with both CCS3.3 and CCS8.1, but we are having trouble with our ethernet output.

I have traced the problem to the initial migration step converting the project from CCS2.21 to CCS3.3.  Rebuilding the project with a new install of CCS2.21, the ethernet output works.  After converting and building the same project code with CCS3.3, the ethernet output fails.

From other posts from many years ago, it seems like there were some migration guidance documents for converting from CCS2 to CCS3 and/or documents on migrating from BIOS4X to BIOS5X, but the posts are so old the links to those migration guidance documents seem to be broken.

Can someone provide me with a working link or reference to those very old migration documents?  Or some other suggestions on what to check for proper ethernet operation when migrating from CCS2 to CCS3?

Thanks,

Bob

  • Hello!

    I don't have the recipe ready to use, but one thing comes to my memory. When we were migrating our old projects, it was 2.1 -> 3.1 -> 3.3. It seems to me that at that latter step 3.1 -> 3.3, when DSP/BIOS configuration through .cdb file was replaced with .tcf script, there was no peripheral initialization. We had C6414 in our system and we used EMIFA to communicate with FPGA. In .cdb config we had all parameters - like read/write strobe, hold width and alike. Once migrated to 3.3 it did not work, so I wrote a routine in C to initialize EMIFA early in main(), and that restored out system. So with this experience in mind I would suggest to see, what kind on hardware configuration was present in 2.x, and what is its counterpart in the latest implementation.

    best

  • I've traced this to what looks like code initializing the DSP Ethernet peripheral where we try to initialize the base address. We do a PCI xfer to command the ethernet to set the base address, but the command never seems to complete. It looks like the ethernet periph is continually busy.

    Does anyone have any info on what ethernet initializations might have changed between CCS2.21 to CCS3 or between BIOS 4.x to BIOS 5.x?

    Does anybody still have a copy of the old migration documents for the BIOS or working links to info on CCS2 to CCS3 migration?

  • I have no experience with PCI on C641x, so I could be of little help here. Still, quick view over PCI peripheral manual shows no hidden setups. So I am curious how exactly Ethernet module is connected to DSP. If that is right on PCI, then I can't imagine, what is wrong between 2.1 and 3.1. Things could be different, if anything is accessed through EMIFs. To my understanding, DSP/BIOS v.4 with CDB configuration was providing a way to statically configure peripherals through CSL. So once you enable CSL in global settings of DSP/BIOS configuration, CSL node appears in config, something like this:

    Here one can see emifaCfg0 is added and its property page. We used this scheme with CCS v3.1. Later, when we migrated to v.3.3 with DSP/BIOS v.5 and TCF type of config script, there was no way to setup peripherals this way, so we wrote C code to do this work.

    So in your situation I would open CDB of v.2.1 and checked, whether any CSL service was in use - see global settings, general, CSL:

    If there is anything, go ahead and see what kind of static configs are there.

    Again, in our case we had no big trouble to migrate working v.3.3 project to Eclipse based CCS, but the problem was to migrate v.3.1 to v.3.3. As you told before, v.3.3 is not operational in your case, so at this point just leave CCS v4 or any later attempts until your v.3.3 project becomes operational, then proceed with import.

  • Hello Robert,

    Please note that TMS320C6415 has no design support as per the product page. That means that we no longer have in-house expertise on this part or its software. rrlagic has more knowledge than I do about the part, so thanks for jumping in!

    However, if you know the titles or the links to those pages that were taken down, I can take a look in the archives and see if I can find you the html source code.

    Regards,

    Nick

  • documents on migrating from BIOS4X to BIOS5X

    I was able to dig up a PDF copy of an old wiki link that covered this topic:

    Migrating from BIOS 4.9 to BIOS 5.x.pdf

    Probably the most useful part of this old doc is the last part: "How do I compare before and after cdb conversion to be sure it's right?

  • Thanks for the pictures.  That helps me find the settings you are referencing.

    But when I open the config tool for my project, it doesn't look like we are configuring any CSL peripherals in the old project.  When I look at the CSL section, I see all the objects, but they all seem to say FALSE for "Enabled" or "In Use".  I'm pretty sure we are using CSL functions, but they all look like they are set up and initialized in code.

    I don't even see any of the Configuration Managers added in our config for any of the CSL devices, so it looks like we are probably configuring all of those in code.

    When I look at  the EMIF registers in our DSP using a debugger and set a breakpoint prior to the ethernet config, I see the EMIF registers loaded with the expected values, so I don't think we are seeing quite the same thing you saw, but I'm still slogging through the rest of the registers.

    But your pictures reminded me that I saw a post earlier about initializing the CSL in code early in the main with CSL_init().  I tried that, but it didn't help fix our problem.

    If you know of any other differences or suggestions you might have run into, the help would be appreciated.

    But thanks for your help so far.

  • Ki, thanks for the document. That gives me a direction for BIOS differences.

    If you know of any similar documents for the other package differences, let me know. (Like the compiler/linker differences or libraries that might have changed.)

    In the meantime, rrlagic was saying they were able to step their project migration through CCS3.1 and had no problem with that step.  I'm wondering if I could divide this migration problem, but I don't see a copy of CCS3.1 on the legacy tools page any more.  Would anyone have a copy of that available so I could divide this between the BIOS change and the compiler changes?

    Thanks.

  • Hi Robert,

    Please start a private E2E conversation with me so we can discuss your options about obtaining CCS 3.1

    Thanks

    ki

  • I am running out of ideas.

    My memory brings me some mess with linker command files, but I can't remember details, so no hints that way.

    Could you please elaborate a bit more about your system, what configurations are taken. What is compiler version you are using with v.3.3?

  • Well, the 3.1 build definitely divided the problem.  It looks like the ethernet fails on the migration from CCS2.21 to CCS3.1, before the big BIOS change, so probably not a BIOS problem. (At least not a BIOS V5 problem.)

    So this is more likely something that changed in the compiler.  (Looks like C6000 compiler V5.1)

    At this point, I'm starting to look through release notes on the CCS3.1 build tools.  If anyone has some old notes or info on things needed to migrate from CCS2.21 to CCS3.1, that would be appreciated.

    Thanks.

  • I looked through the Processor Wiki Archives, and I was able to fine one more page that might be useful on migrating from CCStudio 2.x to 3.1:

    Migration_to_CCStudio31.pdf

    Regards,

    Nick

  • Thanks, everyone, for your help on this.  The documents and CCS versions were a big help in solving the issue.

    The problem turned out to be a CSL change that was done prior to CCS3.1, somewhere after the CCS2.21 version used for the legacy project.  It was the trctl field added to the PciConfigXfer struct in the CSL we were using in our Ethernet config.  In the old code, the original struct fields were all reset to 0 and we filled them all in as part of our PCI xfer cycle. Since there was no need to preserve any data, we didn't read the registers before changing them.

    When the new field was added, the hardware resets trctl to a non-zero value, but the struct was not initialized, so the struct value for trctl got set to 0.  When we tried to write the new PCI_xferConfig values, it wrote the invalid 0 value trctl to the PCI config along with the rest of our PCI parameters and that caused the PCI to die shortly afterward.

    The solution was to read the HW register values using PCI_xferGetConfig to initialize the struct before we set the other parameters, basically doing a read-modify-write sequence for the struct based on the HW register values.  This preserves the original HW reset value for trctl.