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.

Porting an evaluation card platform (C6657)

Other Parts Discussed in Thread: TMS320C6657

While waiting for initial build of our custom hardware (which has a C6657 DSP on it), I've developed and tested a good portion of the software using a TMDXEVM6657LE evaluation card.  With that card, I built with the ti.platforms.evm6657 platform, which I used mainly to communicate with SRIO and with the UART.  Now that our hardware is in house, I am no longer using the eval card exclusively.  Our hardware is slightly different than what was on the eval card, so ti.platforms.evm6657 is no longer the correct platform to use.

My question is:  How do I port the evm6657 platform to work on our hardware?

Initially, all I need to do is modify DDR3 PLL parameters, and set up the EMIF16 bus for our needs.

This is what I tried:

I imported the platform_lib project into my workspace.  So that I wouldn't modify the original code (I need it, because I still do basic development on the eval card), I copied the files to my workspace.  After setting up include folders to be correct, I got the library to compile.  I added it as a linked-file to the app project, and it appeared to link.

When running the app under CCS debug on our hardware, it didn't know where to find the source files (which sent up a red flag).  I pointed it to the source files in my workspace, and the debugger displayed the code correctly.  Using CCS, we modified PLL variables, and we got our DDR3 SDRAM to work.

The next thing I did was to modify my copy of the platform library to use our PLL values.  I didn't delete the original code; instead, I simply #ifdef'd the old code out and the new code in.  I set a breakpoint in the DDR init code, and ran it.  When the breakpoint hit, CCS displayed the source file, but it was on the wrong line (an even more obvious red flag).  It was apparent that the platform library that was linked into my app was the original (with the original source-file line numbers), and that the new one was not linked at all.

I'm sure that this has something to with all the XDC and RTSC stuff that CCS uses.  I don't understand all of that, and our schedule does not allow time for me to figure it out.  Hopefully, someone can point me to some clear, concise documentation that describes what I need to do to make this work.

  • Jeff,

    Can you provide us with more details?

    What product are you using? The library platform_lib: is this part of the product you are using? Can you provide us with the option you set to add the library as linked-file?

    Vikram.

  • I'm not sure what you're asking, but here goes:

    I am using a TI C6657 evaluation card, part number TMDXEVM6657LE.  The platform library was included with MCSDK PDK TMS320C6657, version 1.1.0.3.  Its name is ti.platforms.evm6657.

    I need to modify the platform library to match our custom-designed hardware (different SDRAM, etc.).  That is what I cannot figure out how to do.

    I don't know what you mean when ask for the option I set to add the library as a linked-file - sorry.

    Surely this is a common thing.  I would suppose that most customers would have to do this, and that it would be documented somewhere.  I just can't find where that is.

    Thanks,
    jw 

  • Jeff,

    Here is a list of steps you need to do to modify a MCSDK PDK library: http://processors.wiki.ti.com/index.php/BIOS_MCSDK_2.0_User_Guide#Building_the_Software

    You should not be copying the files into your workspace and building. Please follow the steps in wiki above.

    Hope this helps.

    Vikram.

  • Vikram,

    Thanks for the reply.

    I had already looked in the "build in place" method of porting the platform library.  I had two problems with that method:

    1. If I modify files in the EVM6657 tree, it will break the platform for the EVM6657 eval card.  I need to be able to build for both our hardware and the eval card.
    2. My source-code control system (Git) doesn't play nicely in that scenario.  Currently, all my source code resides in a single tree, and the PDK code is not there.

    I suppose I can work around both of those issues.  Is this the method that other developers use?

    Thanks,
    jw 

  • I used the "build in place" method, and I got everything checked into Git (although I have no Git link between my source code and the PDK code).  I discovered another issue with this method:

    We deliver our code to our customer as a library, which they will link with with their app.  If we modify the PDK, we need to get that to them somehow, as well.  How can we redistribute our modified PDK?  I suppose I could provide the differences as a set of patches, but that just doesn't feel right.

    Once again, surely there are other PDK customers who have done something similar to this.

    Thanks,
    jw