CppUTest 3.5 with Code Composer v5 (target processor = C674x)

[Emmanuel D'ANGELO]

Hi,

I'm currently trying to test CppUTest in our company workflow (for automated testing and eventually TDD). We use as main development environment TI's Code Composer Studio v5 on Windows platforms.

I've successfully managed to compile CppUTest with our build settings. Now, I'm trying to reproduce the LedDriver project from the book TDD for embedded C in the C674x simulator in CCS. After setting up a new project and target executable for the tests, I'd like to see the output of the tests. Where can I get started? I see nothing on the console when running the code in the simulator, and I'm not sure how to enable and use the output buffer option.

Also, from this small experiment, I can already see that the process of compiling + testing takes a lot of time (because of CCS). So, is it a viable way of testing and test-driving in the long term? If not, what tools could we use instead (on Windows)? On *nix, I would start a console with an editor and a simple makefile / cmake file, but I'm not sure I can find an efficient and easy way of doing TDD cycles outside an IDE on Windows.

Thanks for your help,

Emmanuel

[A. Robert S.]

Hi Emmanuel,

 

Are you using the cl2000 platform specific files supplied with CppUTest 3.5? If so, this behavior can be enforced by defining USE_BUFFER_INPUT. It should not occur otherwise.

 

I used a very old version of Code Composer Studio (3.3, I believe) and printf() output was directed to the host's console.

 

As for speed, in my experience running tests this way takes seconds instead of microseconds (factor 1000!) so no, I wouldn't routinely test this way. I would aim at running tests on the host (using gcc) for development, and only run tests on the target infrequently (before releases) to ensure it behaves consistantly. Also, if you go to all that trouble, maybe you will want to run the tests on the real target? It will probably be faster than the simulator, making up for the download time ;-).

 

You can use any IDE on Windows with GCC. Personally, I like Code::Blocks. You can also use make or cmake. For both, you can use either Cygwin or MinGW GCC. Cygwin is quite good nowadays, just make sure you install gcc-c++. Or you can use Eclipse, if you prefer (I understand CCS 5 is based on Eclipse). Important thing would be to specify Cygwin GCC as target (this is possible with 'normal' Eclipse CDT, it should also work with CCS) This way, you just need to create an additional build target for testing on the host, and specify Cygwin GCC as the toolchain to use for it.

 

Easy. And about 1000 times as fast ;-)

 

Regards,

Robert

[Emmanuel D'ANGELO]

Hi Robert,

Thank you for the extended answer.

Are you using the cl2000 platform specific files supplied with CppUTest 3.5? If so, this behavior can be enforced by defining USE_BUFFER_INPUT. It should not occur otherwise.

 

I used a very old version of Code Composer Studio (3.3, I believe) and printf() output was directed to the host's console.

I used the  c2000 platform file as base for a C6000 version, but I can't see any change with or without USE_BUFFER_INPUT enabled. It seems to me that the tests are actually failing, but I don't know why.

- Did you use some special settings (memory leak plug-in enabled / disabled, without standard lib C++…) ?

- Did you have to do anything special to redirect printf() to he console?

As for speed, in my experience running tests this way takes seconds instead of microseconds (factor 1000!) so no, I wouldn't routinely test this way. I would aim at running tests on the host (using gcc) for development, and only run tests on the target infrequently (before releases) to ensure it behaves consistantly. Also, if you go to all that trouble, maybe you will want to run the tests on the real target? It will probably be faster than the simulator, making up for the download time ;-).

Alas, download times are… well… let's just say long. And I don't feel 100% confident launching code on the real device that does not already work in the simulator.

 

 You can use any IDE on Windows with GCC. Personally, I like Code::Blocks. You can also use make or cmake. For both, you can use either Cygwin or MinGW GCC. Cygwin is quite good nowadays, just make sure you install gcc-c++. Or you can use Eclipse, if you prefer (I understand CCS 5 is based on Eclipse). Important thing would be to specify Cygwin GCC as target (this is possible with 'normal' Eclipse CDT, it should also work with CCS) This way, you just need to create an additional build target for testing on the host, and specify Cygwin GCC as the toolchain to use for it.

 

Easy. And about 1000 times as fast ;-)

I understand what you mean. I did try a bit this way today, because f the troubles and because it's also interesting for us (we will have to support multiple platforms, and not only TI, so being as much platform agnostic as possible sounds great to me). However, I wasn't able to get a C++ project to compile properly from CCS. The Eclipse part of this Franken-IDE shows me the toolchain, but can't launch it correctly. I still have to check with our IT guy. If I can't make it work, then I'll go for Code::Blocks or Visual Studio.

- Did you have to install the Cygwin toolchain outside Code Composer or Code::Blocks? I'm sorry if this is some very naive question, but last time I worked in a Windows-operated company we were using NT4 (and had dedicated linux machines to get "real" work done ;-), and I got into a lot of trouble today (still unclear if it is linked to my configuration or to the CCS tool version).

 

Regards,

Robert

Thanks again for taking the time to write a detailed answer. I'll keep you posted when I progress.

Best regards,

Emmanuel

[A. Robert S.]

Hi Emmanuel,

 

I used the  c2000 platform file as base for a C6000 version, but I can't see any change with or without USE_BUFFER_INPUT enabled. It seems to me that the tests are actually failing, but I don't know why.

 

- Did you use some special settings (memory leak plug-in enabled / disabled, without standard lib C++…) ?

- Did you have to do anything special to redirect printf() to he console?

For starters, try enabling USE_BUFFER_INPUT. Look at memory after the test run. Look for "buffer". If it contains no CppUTest messages, something is seriously wrong with your tests. You may want to put an endless loop at the end of your main() to do this.

 

  - I had to disable standard C++ lib on my device (which, importantly, disables exception handling, and I disabled RTTI.

  - Not that I remember. But then, I can't be entirely sure.

 

Also watch out for the following (using the debugger), especially if there is no output at all, not even in the buffer:

  - Is the targets startup code executed before entering main()?

  - Are function calls correctly entered from main (use a simple stub call to make this easier)

 

There are many reasons why your test binary might not even run (properly).

 

Alas, download times are… well… let's just say long. And I don't feel 100% confident launching code on the real device that does not already work in the simulator.

 

Sure. it should run in the simulator, where you don't have to worry about turning of / feeding the watchdog etc etc.

 

I understand what you mean. I did try a bit this way today, because f the troubles and because it's also interesting for us (we will have to support multiple platforms, and not only TI, so being as much platform agnostic as possible sounds great to me). However, I wasn't able to get a C++ project to compile properly from CCS. The Eclipse part of this Franken-IDE shows me the toolchain, but can't launch it correctly. I still have to check with our IT guy. If I can't make it work, then I'll go for Code::Blocks or Visual Studio.

 

Please, don't bother your IT guy just yet ;-). You have to install Cygwin first before it can do its magic. Steps are:

  - download from their web site

  - unzip into a directory where the setup stuff can STAY (don't throw this away!!!)

  - run installer. Use default target directory (C:\Cygwin) or specify your own. Avoid c:\Program Files and their likes.

  - when offered the list of packages, under devel, make sure that gcc-core and gcc-c++ as well as gdb are installed.

  - open c:\Cygwin\Cygwin.bat. This is a *nix shell. type gcc --version to see whether that works and type make. Should work also.

  - Then try again selecting the toolchain in Eclispe.

  - Be aware that cygwin prefers paths of the form /cygdrive/c/...

  - Very important. To be able to replicate the exact same installation, once everything works fine, zip your c:\Cygwin folder into an archive.

 

You can (re-)"install" Cygwin simply be copying and adjusting the system path to contain C:\Cygwin\bin. Or replicate it to co-workers PC...

 

- Did you have to install the Cygwin toolchain outside Code Composer or Code::Blocks? I'm sorry if this is some very naive question, but last time I worked in a Windows-operated company we were using NT4 (and had dedicated linux machines to get "real" work done ;-), and I got into a lot of trouble today (still unclear if it is linked to my configuration or to the CCS tool version).

 

Yes, see above. Eclipse should recognize it automagically when present. 

Thanks again for taking the time to write a detailed answer. I'll keep you posted when I progress.

No trouble. Hope it works for you.

Arnd 

 

[A. Robert S.]

Oops. My formatting didn't turn out as nice as yours :-(.

 

I had the memory leak warning plug-in enabled (as I consider that an important part of testing)

 

Cheers,

Arnd

 

[Emmanuel D'ANGELO]

Hi Arnd,

Thanks for the tips about Cygwin! I managed to install it on my machine.

Here is an update on my progress so far.

I hadn't initially enabled the memory leak warning, because I plan to avoid dynamic memory allocation in the final firmware. We have a closed universe, where all quantities are bounded. Anyway, it does not harm to enable it during the tests.

For now, I've left the Code Composer part away. I upgraded to the latest version and encountered the same issue while running the code in the simulator. What happens is that the execution fails when entering the method RunAllTests() : the program jumps to address 0x0, which is obviously a bad thing here. I didn't have time however to investigate the issue further. I did also manage to install a Cygwin compilation chain that works in the command line but still has some hiccups when launched from CCS.

Eventually, I managed to compile and use CppUTest from VS2012. I feel more comfortabe with this IDE than with CCS, and I don't run into any weird issues. It works like a charm, and compile and execution times are faster :-)
Since we will target many different processors later, it is actually a good thing that I start developing using different architectures and compilers. Now, I'm trying to adhere to TDD principles, which is not so easy when you are used to another form of programming ;-)

Thanks again for your help! I'll update this thread again when I have time to investigate the particular CCS issue.

Cheers,

Emmanuel

[A. Robert S.]

Hi Emmanuel,

 

Glad to be of help. As for memory leaks, it will help you find memory leaks in your test code, if any ;-).

 

Cheers,

(Arnd) Robert