Code Composer - Protecting software IP while enabling customers to add their own code

This is problem involving the tradeoff of code security and customization.  I have come across it before and its a hard one to master.   At one end of the scale is giving the source code / libraries and providing full customization and no code security and at the other is no customization but full code security.

However there are ways around this which allow some customization without invalidating code security.  One way that I have done something similar to would be as follows:

This method involves assigning a certain piece of flash and/or RAM to the customer.  This can be done by using the linker and some function pointers.  Here is a basic step by step method:

1) Allocate some Flash which you arent going to use in your main program.  I suggest a full bank (e.g. FLASHB).  Make sure none of your main product code uses this bank. Also allocate an unused piece of RAM for his use.

2) Next you will need a bootloader which can erase/load only certain sectors of the code.  I am not sure if the onboard bootloader can do it (I am leaning towards no) so if it doesn't then you will need to make a custom bootloader using the Flash API.  This would basically take a file in from a communications port (I used SPI for mine but UART would work well), parse it, erase and program the flash and run checksums.  I would suggest you send a binary file with the code.  In order to generate this binary file I used the utility hex2000 (comes with the code gen tools) to convert .out into .hex and then wrote a custom windows program to convert .hex into a binary stream in the format I wanted.

3) In your main code you will need to assign a function pointer to point to the start of the assigned flash. This will allow you to call the user code.  You also want a CRC checking function (I used a CRC16) so that you can ensure that the user code loaded is actually valid.

4) When the user code is to be called: Make sure the code is valid.  Call the function pointer.

5) Now comes to the part of allowing the user to write code.  The best way is providing a shell program which basically boots up and runs.  This IP is generally shared (TI examples etc.).   You will need to tell your user to use #pragmas and assign all his CODE_SECTIONs and DATA_SECTIONs to specific areas such as user_data and user_code. Also they will need to assign a function called user_boot() to its own section such as user boot. Now in their linker file you do the following:

user_boot : > FLASHB

user_code : > FLASHB

user_data : > ALLOCATEDRAM

This will mean that all his code will be placed in FLASHB.  More importantly right at the top of FLASHB will be a function to start the code.  This is where the earlier function pointer points to.

6) Now you make a small program to convert the .out into a format you want and stripping all but the FLASHB data.   This can be then loaded in the bootloader.

A couple of sundry points:

1) This is much easier if the user code is to do a specific job e.g. a single function that converts one value to another.  Full customization leads to issues of whether the main programs data space is being corrupted by the user code or not.

2) The user code should not touch the peripherals.  In order to allow use of the peripherals you will need to implement interface functions which are in a table in a fixed location (like a vector table).

Hopefully you can understand the above method.  If you have any questions I'll try to answer them.

Tim

Answers:

1) Yes this will allow the user to debug their own code standalone in CCS.  However not with your code in CCS (you would have to provide source code etc for this to work).

2) No.  The product it was in did not reach market due to other circumstances.

3) It would be awfully hard to 100% ensure customer code did not inadvertently access your main code using a simple customization method.  You will have to rely on giving the customer a fixed set of rules - use this RAM, use this FLASH but if they really want to they can access other areas.  Using the Code Security Module on the C2000 creatively may offer some solutions. Other methods involve either writing the compiler or seeing the customers code.

What I did was an update mechanism for my own code.  It allowed me to update my code on the fly without affecting it running by loading it in a particular section of flash in parallel.   What I outlined above was what I thought would work in doing it as a customization method by developing and loading the customers code in parallel.

Hopefully my posts have given you some ideas.  Its a fine line allowing customization whilst not providing the IP. 

Tim