How to ensure a custom platform is built before a project builds?


I am running CCS

I realise that a custom platform is automatically built whenever it is modified using the RTSC Platform Wizard.  However, in our development environment we store our source files in Subversion (version control system). It is possible that developer (A) will commit a modified Platform.xdc file to the repository and another developer (B) will update to the changed version, without running the platform wizard.  In this circumstance, how can I ensure that the platform will be rebuilt when developer B rebuilds his local copy of the project?

Best regards


  • Keep these files checked in to version control once the Platform is created with the GUI:






    All other files (.libraries, .executables, etc) are generated at build time each time you build and should not be version controlled.  If the platform is changed by developer A, developer B getting the latest revision will change the above files.  When the project is rebuilt by developer B, the executable will use the new settings.

  • In reply to Nick Bedbury78040:

    the answer depends on the workflow in your team. If you normally build packages on the command line, as you had to do in the other thread, then Nick's advice applies. Even if you mostly use the Platform Wizard, but you don't mind rebuilding the package on the command line every time you check it out from a version control system, you can still keep only the sources under version control.
    However, if you only change platform packages, and you change them only using the Platform Wizard, and you don't want to ever build from the command line, then you might need to keep everything in the platform package under version control.

    If you keep only the source files under version control, and you check out the sources into a new directory, the Platform Wizard won't find the platform because the Wizard must be able to read the content of the directory 'package' to recognize that a package contains a platform. If you check out the sources into a directory that already contains an already built platform package containing the directory 'package', the content of the directory 'package' could be outdated, but it would be still displayed in the wizard. Any further change will be written over the checked out file Platform.xdc.

    If you keep everything under version control, every time someone changes the platform in the Platform Wizard, the package will be rebuilt and the content of the directory 'package' will be in sync with Platform.xdc. They weren't in sync in the other thread because one file is missing from 'package', but if you keep 'package' consistent, the Wizard will rebuild the whole package whenever needed.

  • In reply to Sasha Slijepcevic:

    Hi Nick and Sasha, thanks for your answers.

    Sasha, thanks for tracking me here from my previous thread. I thought it best to start a new thread because I marked the other one as answered. From your replies, I can think of two ways forward presently:

    1) Add package.xdc.dep to version control.  Actually, I haven't made this work - after adding it I still get the problem reported in the previous thread.  But I think this has to do with xdc.exe clean upsetting the version control by deleting metadata in the package folder.

    2) Following Nick's advice. Commit the bare minimum files to Subversion and use xdc.exe to build the platform. But I don't really want every developer to have to remember to do this.  This brings me back to my original question in this thread.  Can I add a make dependancy in the CCS project to invoke xdc.exe on the platform whenever I build the project? 


  • In reply to David Aldrich92784:

    1) If you have package.xdc.dep, and the java file is not rebuilt even after you update Platform.xdc, I would like to take a look at that package. 

    2) You can create a separate project that rebuilds the platform package every time you build your main project. Your platform project should be created as a "Makefile project with existing code". You’ll have to specify ‘xdc’ as build command for that gmake project. See “Build command” below.

    Then, in the main project, in Properties->CCS Build->Dependencies, add your platform project as a dependency.

  • In reply to Sasha Slijepcevic:

    Hi Sasha

    1) I have now fixed the problem with including package.xdc.dep in version control.  I was running a version of xdc.exe from the command line that was different to the version used in CCS 5.1.  I have now used the same version and package.xdc.dep is in version control. This seems to be an adequate solution.

    2) Thanks for your suggestion of using a dependant project. That helps my understanding.

    I think I am sorted now. Thanks for your help.


  • In reply to David Aldrich92784:

    Thanks for this thread, I've been struggling with the same issue.

    For TI, I think there are three "pain points" here with CCS, all of which could use a little work:

    (1) Making xdc.exe play nicely with Subversion.  It's OK if you only check in sources, but checking in "built" packages causes problems.  (a) it isn't clear which files you need, and (b) "xdc clean" deletes the package/ subdir which annoys and confuses SVN.  If you can't check in the build package, then everyone who checks it out HAS to be able to build the platform package.

    (2) The platform wizard isn't integrated with the Project settings or makefile generation, whereas sometimes it would be really nice just to check a box and say "this platform.xdc is part of this project build".

    (3) The absence of direct and obvious support for xdc-built component packages in CCS is mystifying, given their importance in the TI narrative.  Yes, I know you can treat XDC as a custom-makefile tool as in the (helpful) example given, but surely CCS could be a bit more aware than that?  (This is a generalisation of (2), to other kinds of XDC-built packages, especially libraries)

    (4) At least for the C66xx Keystone devices, the platform de-facto includes important linker memory map definitions that cannot be overridden in the .cfg file.  This is what creates much of the software coupling and the need for the platform to be updated most often for us.  If the semantic rather than hardware aspects could be decoupled, you would have less need to fiddle with the platform package and could use the "stock" EVM platforms more.

    My ideal would be for the "platform" package to define physical ranges for "DDR3", "L2SRAM", "MSMCRAM" etc. and .cfg file be able to define named subareas of these as linker section.  At present this is not quite possible, so you end up doing things like the following (from the MCSDK!) which is effectively an application-specific partition of the MSMCRAM physical area, and therefore the application requires a custom platform even on an EVM.  It also includes things like access bits and L1 and L2 cache sizes that cannot be overridden in the .cfg, but again are really application-specific settings rather than attributes of the hardware platform.

                            name: "MSMCSRAM_MASTER",
                            base: 0x0c000000,                    
                            len: 0x00100000,                    
                            space: "code/data",
                            access: "RWX",
                            name: "MSMCSRAM_SLAVE",
                            base: 0x0c100000,                    
                            len: 0x00100000,                    
                            space: "code/data",
                            access: "RWX",
                            name: "MSMCSRAM_IPC",
                            base: 0x0c200000,                    
                            len: 0x00200000,                    
                            space: "code/data",
                            access: "RWX",

    OK, rant over for now.  :-)

  • In reply to Gordon Deane:

    Hi Gordon

    Thanks for your analysis of the problem. I hope that TI takes notice.

    Best regards


  • In reply to Gordon Deane:

    thanks for your rant post, it does bring up some issues that we would like to address, but as everyone else we have to prioritize work items based on how loudly customers ask for them. Without promising anything about future enhancements, I'll try to comment on some of the topics in case you can solve some of the problems with the current tools.

    1) When the Platform Wizard builds a platform package, it also creates a zip file which contains all the files needed to use the platform. So, the users who do not make any changes could only check out the zip file, extract the files and use the platform without building it. So, if you keep the sources and the zip file under version control, you could avoid the need for rebuilding at least for some users, and also avoid checking in the directory 'package'.
    I am not sure what we could do to make XDCtools create svn-friendly packages. If the problem with svn and the removed directories is caused by the removed .svn directory inside the directory 'package', then upgrading svn may solve the problem because I think they switched to one .svn directory on the top instead of .svn directories everywhere.

    2) I would also like to get there sooner rather than later, where you would say "this platform package is part of the project build", and 3) would be "this <whatever> package is part of the project build". I am not aware of any plans for that right now, but that could change. 

    4) This is actually a common request because that's how DSP/BIOS 5 worked. The difference is that now the config script is not exclusively a SYS/BIOS config script, but there could be multiple packages involved in a configuration (BIOS, IPC, cfg script as a part of a special package, NDK, possibly others), and each of these packages could contain some logic that depends on the content of the memory map. Therefore, the map can't change as soon as any of the packages had a chance to read it, which could be the first statement in the script.
    Currently, we solve it by defining the memory map in a platform package, which then prepares the memory map before the script starts and makes the map readonly in the config script. We are looking for better alternatives, and this item is most likely to get a lot of our attention soon.

  • In reply to Sasha Slijepcevic:

    Fair enough, I was having a rant, and don't mean any offense.  Believe it or not, I'm actually defending CCS around here now.  Some of my colleagues had a bad experience with a CCS 4/C64xx project a few years ago and won't go near it, but I'm actually coming to like the tools.  With a few reservations ;-).  I also think it's easy on forums like this to focus on the immediate problems people express rather than the broader design issues that would fix them properly, and I liked this thread because it was a bit more "big picture".

    Under (1), I'm aware of the ability to do release/install steps, but haven't managed to build that into our workflow.  The DSP code is part of a larger SVN tree and people want to be able to "check it out and just build it".  I think if you managed to decouple the application-specific memory map from the platform details as you discuss under (4), then this would work better.  We would then only have to issue a new platform very occasionally (eg. along with a board spin) and could use the RTSC versioning to detect if people hadn't upgraded.  On the EVMs, I could imagine not having a custom platform at all and just using the xdctools package, which would be great.

    Regarding newer SVN working better with XDC, I didn't know that, but will certainly try it.  Thanks for the tip.

    For now, I like the technique you posted above (22 Mar) of having a separate project in the workspace which builds the platform, and will try to implement it when I get a chance.  (Rant aside, this isn't actually a day-to-day problem at present).



  • In reply to Gordon Deane:

    As a further note, creating a "Makefile project with existing code" in CCS 5.1 just didn't seem to work.  The "Build" options were entirely missing, and the .project file created was totally gutted as below.  In particular, comparison with working projects suggests that the <buildSpec> section is AWOL.  I needed to create a non-CCS "C/C++" project with an arbitrary toolchain and then select an external build tool.  This was a bit non-obvious but seemed to work.

    <?xml version="1.0" encoding="UTF-8"?>