CppUTest in KEIL on Windows

[andreas]

I'd like to join Heath Raftery who wrote a very helpful setup-guide. I made the same excercise for Keil uVision lately, here are my findings:

Toolchain:
uVision MDK-ARM Standart Version: V4.70.0.0
Compiler / Linker Toolchain Version: V5.03.0.24

HAL Library:
Standard Peripheral Library for STM32 Cortex M3 Version V3.5.0

Target:
STM32F103VG

I chose to set up a simulator project, most because I like the idea of being able to testdrive code before any HW is present. Furthermore I am testing with the same compiler toolchain as my target will use, and last but not least, code coverage / and performance analysis are available in the same environment. Drawback is, that you are kind of stuck to the keil environment. The editor is not a big revelation, nor is the toolchainsettings and the possibilities to automate the tests. But that is whole different story...
I picked the biggest (memory-wise) available CortexM3 core from ST (STM32F103VG) that has a simulator available, since we are using a core of the same family. Check yourself if Keil provides a simulator for a certain core on the Keil webpage.

• To build the CppUTest library in Keil, I created a new empty Keil project in the root folder of cpputest and made the following changes:
• Target Options->Device Tab->choose "STM32F103VG"
• Target Options->Target Tab->Code Generation->check "Use MicroLib"
• Target Options->Output Tab->Create Executable lib
• Target Options->C/C++ Tab->Define->add "STM32F10X_XL,  CPPUTEST_STD_CPP_LIB_DISABLED"
• Target Options->C/C++ Tab->Include Paths->add the CppUTest include directory
• Target Options->C/C++ Tab->Misc Controls->add "--diag_suppress 1300 --diag_suppress 1293  --exceptions"
• Target Options->Linker Tab->Misc Controls->add "--vfemode=off"
• added all *.cpp files in src\CppUTest\
• Added src\Platforms\Iar\UtestPlatform.cpp
• Changed in UtestPlatform.cpp the return value of the function TimeInMillisImplementation from return 1; to return t; which enables timing.
• in UtestPlatform.cpp I declared all the functions except for PlatformSpecificRunTestInASeperateProcess and PlatformSpecificGetWorkingEnvironment as extern "C"
• CppUTest builds with these settings, generating a CppUTest.lib file
• To build the CppUTest tests, I created a new empty Keil project in the root folder of CppUTest, called it CppUTestTest, and made the following changes:
• Target Options->Device Tab->choose "STM32F103VG"
• Target Options->Target Tab->Code Generation->check "Use MicroLib"
• Target Options->Output Tab->Create Executable (not Lib) check "Debug information"
• Target Options->C/C++ Tab->Define->add "STM32F10X_XL,  CPPUTEST_STD_CPP_LIB_DISABLED"
• Target Options->C/C++ Tab->Include Paths->add the CppUTest include directory
• Target Options->C/C++ Tab->Misc Controls->add "--diag_suppress 1300 --diag_suppress 1293  --exceptions"
• Added the include path to the Standard Peripheral Library from STMicroelectronics
• Added the include path to the ARMCC standard implementations
• Target Options->Linker Tab->Misc Controls->add "--vfemode=off"
• Target Options->Debug Tab->check "Use Simulator"
• Target Options->Debug Tab->create a map.ini file that contains the memory regions with the appropriate permissions
• Target Options->Debug Tab->Parameter->add "-REMAP"
• Add all *.cpp and *.c files in tests\
• Add the startupfile for the core. In my case it is "startup_stm32f103x_xl.s"
• Add the system init file, in my case "system_stm32f10x.c"
  
• Add the previously built CppUTest.lib
• change the file AllTests to be able let the tests run in verbose mode
  int ac_override = 2;
  const char * av_override[] = { "exe", "-v" }; //turn on verbose mode
  return RUN_ALL_TESTS(ac_override, av_override);
• since Keil does not support semihosting straightaway, you need to retarget some functions. A working retarget sample can be found from this website. Basically what must be done is redefining fputc to redirect the debug output over the ARM ITM interface. Something like this:
  #pragma import(__use_no_semihosting_swi)
  #define ECHO_FGETC
  volatile int ITM_RxBuffer=0x5AA55AA5; /* Buffer to transmit data towards debug system. */
  
  struct __FILE { int handle; /* Add whatever you need here */ };
  FILE __stdout;
  FILE __stdin;
  
  int fputc(int ch, FILE *f)
  {
    return (ITM_SendChar((uint32_t)ch));
  }
• Furthermore, a working clock definition is needed. Keil provides an example here.
  

Here we are. With this I had a working CppUTest environment under Keil. Debug output (Test results) can be listed via "View->serial Windows-> debug (printf) viewer". I am going along this street now, creating a custom testdriven project. If you admins think it would be useful to create a UtestPlatform.cpp for Keil let me know, I am happy to share my files.

Andreas

[Erick van Rijk]

Hi Andreas,
Thanks for the setup guide, I've been playing around with Eclipse/Keil/CppUTest for a while now and never really got it working right.
I'll give it another shot!

Erick

[Erick van Rijk]

Andreas,
would you mind adding your project files to Github?

Erick

[andreas]

Erick,

I can do so for the "UtestPlatform.cpp" file. The "retarget.c" file and the "clock_impl_cm3.c" have keil respectively ARM copyrights, and I don't feel comfortable loading them on github - but I gave you the links where you can download them. I will try to add the "UtestPlatform.cpp" tomorrow, as I am out of office today. Just wondering, are you having troubles somewhere??

BR Andreas

[Erick van Rijk]

Hi Andreas,
I'm having the obvious unresolved symbol errors.
*****
compiling retarget.c...
compiling clock_impl_cm3.c...
linking...
.\cpputesttest.axf: Error: L6218E: Undefined symbol time (referred from utestplatform.o).
Not enough information to list image symbols.
Finished: 1 information, 0 warning and 1 error messages.
".\cpputesttest.axf" - 1 Error(s), 0 Warning(s).
*****

So I was hoping to glean any obvious mistakes from your uvproj.
uVision does list the time.h correctly from the C:\Keil\ARM\ARMCC\include (any other obvious locations for time?)
Assuming the lib does build correctly (it doesn't give any errors) I must have made and editing error somewhere. If you can supply the UtestPlatfrom.cpp, it would be helpful. (could be a simple typo).
Thanks
Erick

[andreas]

Erick,

I am feeling guilty for this... I forgot to tell about one more change to be made in order to make it work:

In the File UtestPlatform.cpp, change the method TimeStringImplementation as follows:

static const char* TimeStringImplementation()
{
    time_t tm = 0;//time(NULL);
    return ctime(&tm);
}

I didn't hunt this down, so I can't tell you why this is necessary, and right now I have no time to do it, but I should...

Hope this helps!
Andreas

[Erick van Rijk]

Great, that resolved the time symbolic issue.
I'm not getting any linker errors any more and after poking at the mem.ini no more warnings there. (could you post your mem.ini contents?)
My next isssue seems to be getting output to debug printf. I got it working properly with the tutorial you provided but I'm not seeing any output, so thats my next hunt for this morning ;)

[andreas]

this is the map.ini that I am using so far - although I am not sure if it is complete...

MAP  0x00000000, 0x000FFFFF  READ EXEC WRITE    // ALIASED FLASH
MAP  0x08000000, 0x080FFFFF  READ EXEC            // FLASH MEM
MAP  0x20000000, 0x20017FFF     READ EXEC WRITE    // SRAM

MAP  0x1044EBC0, 0x1044FFFF  EXEC READ    // unclear

MAP  0x1FFFE000, 0x1FFFF7FF     READ EXEC WRITE

MAP  0x20018000, 0x3FFFFFFF     READ WRITE

MAP  0x40000000, 0x400003FF  READ WRITE
MAP  0x40000400, 0x400007FF  READ WRITE
MAP  0x40000800, 0x40000BFF  READ WRITE
MAP  0x40000C00, 0x40000FFF  READ WRITE
MAP  0x40001000, 0x400013FF  READ WRITE
MAP  0x40001400, 0x400017FF  READ WRITE
MAP  0x40001800, 0x40001BFF  READ WRITE
MAP  0x40001C00, 0x40001FFF  READ WRITE
MAP  0x40002000, 0x400023FF  READ WRITE

MAP     0x40003C00, 0x40003FFF  READ WRITE // SPI3

MAP  0x40007000, 0x400073FF  READ WRITE
MAP  0x40010000, 0x400103FF  READ WRITE    // AFIO
MAP  0x40010400, 0x400107FF  READ WRITE    // EXIT
MAP  0x40010800, 0x40010bFF  READ WRITE    // GPIOA
MAP  0x40010C00, 0x40010FFF  READ WRITE    // GPIOB
MAP  0x40011000, 0x400113FF  READ WRITE    // GPIOC
MAP  0x40011400, 0x400117FF  READ WRITE    // GPIOD
MAP  0x40011800, 0x40011bFF  READ WRITE    // GPIOE
MAP  0x40011C00, 0x40011FFF  READ WRITE    // GPIOF
MAP  0x40012000, 0x400123FF  READ WRITE    // GPIOG
MAP  0x40012400, 0x400127FF  READ WRITE    // ADC1
MAP  0x40012800, 0x40012bFF  READ WRITE    // ADC2
MAP  0x40012C00, 0x40012FFF  READ WRITE    // TIM1
MAP  0x40013000, 0x400133FF  READ WRITE    // SPI1
MAP  0x40013400, 0x400137FF  READ WRITE    // TIM8
MAP  0x40013800, 0x40013bFF  READ WRITE    // USART1
MAP  0x40013C00, 0x40013FFF  READ WRITE    // ADC3

MAP  0x40014C00, 0x40014FFF  READ WRITE    // TIM9
MAP  0x40015000, 0x400153FF  READ WRITE    // TIM10
MAP  0x40015400, 0x400157FF  READ WRITE    // TIM11

MAP  0x40018000, 0x400183FF  READ WRITE    // SDIO

MAP  0x40020000, 0x400203FF  READ WRITE    // DMA1
MAP  0x40020400, 0x400207FF  READ WRITE    // DMA1

MAP  0x40021000, 0x400213FF  READ WRITE    // RCC

MAP  0x40022000, 0x400223FF  READ WRITE    // FLASH INTERFACES 1&2

MAP  0x40023000, 0x400233FF  READ WRITE // CRC


MAP  0x40021000, 0x400213FF  READ WRITE
MAP  0x60000000, 0x63FFFFFF     READ EXEC WRITE
MAP  0x70000000, 0x73FFFFFF  READ EXEC

MAP  0x78000000, 0x78FFFFFF     READ EXEC // FSMC BANK 2


BR Andreas

[Bas Vodde]

Hi Andreas,

Thats pretty kewl. I like that.

Terry had actually put Heath’s description on cpputest.org at:
http://cpputest.github.io/stories.html

I noticed that there was no easy to way get to that page, so now I added it in the menu.

Would you mind adding your story too or shall I try to see if Terry can do it again?

You can find the page at:
https://github.com/cpputest/cpputest.github.io/blob/master/stories.markdown

Let me know if you need help on it!

Thanks,

Bas

> --
> You received this message because you are subscribed to the Google Groups "cpputest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cpputest+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Erick van Rijk]

Ok, that Map.ini file is more extensive that the one I made. Thanks.
Seems that the fputc function is never called in debug. It seems to be stuck in startup_stm32f10x_xl Systick handler.
Did you perhaps modify the standard simulator config for the device target (i.e. R/W memory areas?/ Stack/Heap?)?

[andreas]

Hi Bas,

That is something for the coming year - I'll give it a try and let you know in case I need support...

Cheers,
Andreas

[andreas]

Nope, no changes done in the startupfile... BUT, another one I missed in my Docu - cool that you are verifying the stuff Erick:

change line 11 from clock_impl_cm3.c to
#define CPU_MHZ        (72*1000000)
Line 36 in the same file to (beware of upper/lower case)
extern __irq void SysTick_Handler(void)
Line 62 in the same file to
static unsigned int overflows = 0;// = systick_overflows;

Hmm - sorry again, hope the is the end of the ladder to success...

Andreas

[Erick van Rijk]

No Worries,
its in my own interest to get this working.
Made the changes, but I'm still not receiving any output in the debug window.
Any other changes, you can think of? Or should I send you my files so you can do a diff?

[Erick van Rijk]

Narrowed it down a bit more,

The debug run ends up in: BusFault_Handler in the startup_stm32f10x_xl.s again. I'm assuming that there is some read/write error that causes this.
Tracing the code (yay simulator), the calling function is from UtestPlatform.cpp:
char* PlatformSpecificStrCpy(char* s1, const char* s2)
{
   return strcpy(s1, s2);
}
s1 = char* 0x18
s2 = char* 0x19

Eventually originating from SimpleString::SimpleString(const char *otherBuffer)

Any idea what's going on there?

[andreas]

Are you trying to write to a memory region that is not declared in your ini file? (check the command window in the debugger. This was in my case the most frequent reason why I would have entered a Busfault...

Andreas

[Erick van Rijk]

Actually I progressed a bit after that last email, Increasing the Heap/Stack to 0x0400 / 0x5000 resolved the BusFaults, (used the suggestions of the IAR howto).
So, After the heap increase and removing the MemoryLeakTests from the sources I finally got the debug printf outputs.

I think you are right that my memory allocations are wrong, I looked at the memory map in the STM32F103xF documents and I cannot seem to spot any errors,
Increasing the heap/stack too large will cause it to run over into the 0x2001 8000 (RESERVED) range.

There are not any errors in the command windows (at least not when I don't push the heap into the RESERVED range.
I do however get the following error when loading the map.ini. Do you get the same error?
*** error 129: MapMem - map size truncated to 128MB

[andreas]

Yes I do get the same error - in the map.ini file you need to define chunks of memory that are smaller than these 128MB in order to get rid of this error...

[Erick van Rijk]

I actually made a mistake with the previous stack/heap comments. https://github.com/cpputest/cpputest.github.io/blob/master/stories.markdown recommends 0x600 and 0x8000. 0x500 abd 0x5000 are for normal use (ie not running the test suite).
So without the memory leak tests: Errors (3 failures, 264 tests, 251 ran, 443 checks, 13 ignored, 0 filtered out, 140 ms).
So it completes the tests. One thing surprises me that it ends up in the hard-fault handler after completion? Is this expected behavior form CortexM3?

3 tests seem to fail, I'll figure them out later. When I add back the MemoryLeakTests it indeed generates an access error:
*** error 65: access violation at 0xF019A814 : no 'read' permission
But the 0xF range is 512-Mbyte block 7 Cortex-M3's internal peripherals. It shouldn't be going here anyway.

If I'm correct you do include the MemoryLeakTests to your project?

[Erick van Rijk]

Andreas,
post holiday update.

Seems that the ARM compiler/microlib fiddles with the NaN a bit. (see http://infocenter.arm.com/help/topic/com.arm.doc.faqs/ka4263.html ) it returns 0 instead of NaN.
What are your experiences?

[andreas]

Erick,

Happy new Year :-)
First I'll clarify the Memleak quest. Nope I've excluded the MemleackTests for now. I didn't hunt it down yet but it does not work here either!
I guess your question regarding NaN points to the same direction. I suppose you are having troubles with all the TESTS that concern double handling. But again, I excluded the tests for now, in order to get back to my project and get ahead there.

[Erick van Rijk]

Ah ok, at least it means we have the same issues.

Have you looked into what the minimal requirements are to run CPPUTest in your own projects?  I haven't even started in implementing that yet.
I'm interested in what a minimalist lib (but still functional) would look like (requirements, not the bits :P)

Erick

[Bas Vodde]

Hi Erick,

On 9 Jan, 2014, at 6:42 pm, Erick van Rijk <erick....@gmail.com> wrote:

> Ah ok, at least it means we have the same issues.
>
> Have you looked into what the minimal requirements are to run CPPUTest in your own projects? I haven't even started in implementing that yet.
> I’m interested in what a minimalist lib (but still functional) would look like (requirements, not the bits :P)

I’m not sure what the minimal requirements are, but usually most compilers that have some sort of C++ support will do. I’ve ones had a C-only compiler, that didn’t work :)

Bas

[Erick van Rijk]

Hi Bas,

I actually mean hardware requirements (since we are testing on embedded devices).
So stuff like Heap/Stack/code/ram size are important.

Erick

[A. Robert S.]

Erick,

 

I used CppUTest with TI's TMS320F2335. I got everything to work, eventually. But I could not get the compiler to produce NaN. I tried many ways to force it, but no luck. So I ended up with three failing tests (the ones that do tests related to NaN). All other tests related to DOUBLE should pass, though.

 

Robert

On Thursday, January 9, 2014 11:23:28 AM UTC+1, andreas wrote:

[Erick van Rijk]

Hi Robert,

I suspect that most ARM system doens't really support the concept of NaN (see my post previously).
If you got the memtest working, I should give that another look when I get the time. Any suggestions what you changed to get it working?

Erick

[A. Robert S.]

Well... I re-read the entire thread and, apart from the general memory-related problems, I can't really tell what went wrong specifically with your memory leak tests?

 

Could you run one of those tests with the -nTEST_NAME option, so it will run only one test? (there is an example of how to hardcode command line options in the cl2000 project folder, assuming your embedded target doesn't take any).

 

Robert

[Bas Vodde]

Hi Erick,

Ah ok. I actually don’t know. We’ve only ones had someone who said CppUTest didn’t fit, but I believe that was incorrect in retrospect.

So, I’m not quite sure how much is needed, we’ve not been hitting the limit of most people it seems… (or they gave up :P)

Bas

[Erick van Rijk]

If I find some time I'll need to take a look at it. CppUTest seems useful, but depending on the requirements it might be just to big for practical implementations for embedded arm devices. (ie Cortex etc).

If I do i'll let you guys now.
Erick

[A. Robert S.]

Hi Erick,

 

Most of us actually do testing with CppUTest off-target. I believe this helps with writing platform-independent code. Of course, that leaves out code that depends directly on hardware functions. Some of this can be tested with plain C tests. But there is a point where you also need to stimulate the hardware in some way or other. At work, very expensive test-debugging environments (hard- and software) are used for this. Privately, I haven't found a good way to deal with testing that kind of code. So I try to move as much functionality as I can into software modules (that can be tested off-target), and the rest is tested manually. I find this is a good discipline - a leap year calculation has no business in the low-level clock driver, for instance. It can live in a library, which can be tested.

 

There is a place for running CppUTest tests on target, but this is expensive in terms of time, both for development and actually running the tests.

 

Low-level device driver code often sets or gets hardware registers, or single bits thereof. The most common source of error would be working with the wrong register or the wrong bit (misunderstanding the devices documentation, for example). Theoretically, I could test code like that by substituting all those registers with memory locations. This would be relatively easy, even without CppUTest. But what would be the point? If I got something wrong, then my test will pass (because I constructed it with my faulty understanding), and my code will still fail on the actual device. Conversely, my (faulty) test might fail, but the code would actually run fine on the real device. Therefore, privately, I don't do these kinds of tests, as I don't have the kind of equipment to support this.

 

All the best,

Robert

[Erick van Rijk]

Hi Robert,

I do understand that the practice of off-target code is useful. But like you mentioned mockups of a hardware level items ADC/pwm/other nasty ARM stuff, is costly to write. Keil actually has this internally in their simulator, hence the interest in running "on-target" either on actual hardware or simulator.

On larger note, I'm also interested in running CppUTest as a CI check in Atlassian Bamboo. Which is a different beast altogether. Basically I'm trying to wrap my head around if CppUTest is useful for production work.

As I go along i'm still learning TDD and to best way of using it. There is a lot of resistance here (office) and If I want to make a proper introduction it will need to work well.

We will see how far I get with TDD/CppUTest. ;)

Erick

[Stefan]

Hi,

thank you all for positing your helpful inputs. I have managed to get CPPUTest running.
My problem is that I need to get it running without using microlib.

has anyone managed to to this? I get following error:

Error: L6200E: Symbol __stdout multiply defined (by stdio_streams.o and retarget.o)


thanks for your help

Best Regards
Stefan

[Vitaliy Bortsov]

CppUTest at github have working ARM C/C++ compiler port. Look at README_InstallCppUTest.txt
I write startup files to ARM7 and Cortex-M3 targets, look at platforms_startup/armcc directory. Also have look at platforms_examples/armcc too.

вторник, 28 октября 2014 г., 20:07:00 UTC+5 пользователь Stefan написал:

[Stefan]

Hi Vitaliy,
thany you for your hints.

I have found the problem. In order to us it without microlib the UtestPlatform.cpp file in the ARMCC platform specific folder has to be modified.

In the function PlatformSpecificFOpen => replaced with return 0;
In the function PlatformSpecificFPuts => empty function
In the function PlatformSpecificFClose => empty function
I guess they could also be handled in the retarget.c file, but this is not the case

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka11357.html

then there was an other problem with the clock. This fixed it for me:
In the function TimeInMillisImplementation() => clock_t t = 0;

So far it seems to work for me. As other already mentioned STACK and HEAP have to be increased. 0x600/0x8000 works for me.

Best Regards
Stefan

[Vitaliy Bortsov]

Hello, Stefan.

fopen() fputs() etc is handled in Keil libraries, which calls user-specified functions written in Retarget.c
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka11357.html

There are two possibility to do retargeting standard I/O to user-defined functions (

Direct semihosting C library function dependencies http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471k/pge1358787045051.html and

Indirect semihosting C library function dependencies http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0475k/chr1358938918384.html)

I preffer to use direct semihosting. It seems that you use indirect one, code at platforms_startup is not suitable for that.

[Vitaliy Bortsov]

Look at that
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0475k/chr1358938918384.html
and that http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0475k/chr1358938918384.html
I use redefining system I/O functions instead of redefining the low-level library functions.

[Stefan]

Hi Vitaliy,

thank you for the clarification. I will try to change this.

Regards
Stefan

[ALSTON NEIL Gama]

Hi Andreas,

 

I have been searching for an unit tetsing framework to intergrate with Keil uVision for testing. I found Unity and its working with Keil. But i wanted something to go with CPP. I will try something that you have tried here.

 

I need a favour from you. I am not able to find a document listing all avalibale frameworks. In case if you have any pointers would really helpful.

 

Thanks in advance.

 

Regards,

Alston Gama

On Thursday, December 12, 2013 at 6:27:50 PM UTC+5:30, andreas wrote:

I'd like to join Heath Raftery who wrote a very helpful setup-guide. I made the same excercise for Keil uVision lately, here are my findings:

Toolchain:
uVision MDK-ARM Standart Version: V4.70.0.0
Compiler / Linker Toolchain Version: V5.03.0.24

HAL Library:
Standard Peripheral Library for STM32 Cortex M3 Version V3.5.0

Target:
STM32F103VG

I chose to set up a simulator project, most because I like the idea of being able to testdrive code before any HW is present. Furthermore I am testing with the same compiler toolchain as my target will use, and last but not least, code coverage / and performance analysis are available in the same environment. Drawback is, that you are kind of stuck to the keil environment. The editor is not a big revelation, nor is the toolchainsettings and the possibilities to automate the tests. But that is whole different story...
I picked the biggest (memory-wise) available CortexM3 core from ST (STM32F103VG) that has a simulator available, since we are using a core of the same family. Check yourself if Keil provides a simulator for a certain core on the Keil webpage.

• To build the CppUTest library in Keil, I created a new empty Keil project in the root folder of cpputest and made the following changes:
• Target Options->Device Tab->choose "STM32F103VG"
• Target Options->Target Tab->Code Generation->check "Use MicroLib"
• Target Options->Output Tab->Create Executable lib
• Target Options->C/C++ Tab->Define->add "STM32F10X_XL,  CPPUTEST_STD_CPP_LIB_DISABLED"
• Target Options->C/C++ Tab->Include Paths->add the CppUTest include directory
• Target Options->C/C++ Tab->Misc Controls->add "--diag_suppress 1300 --diag_suppress 1293  --exceptions"
• Target Options->Linker Tab->Misc Controls->add "--vfemode=off"
• added all *.cpp files in src\CppUTest\
• Added src\Platforms\Iar\UtestPlatform.cpp
• Changed in UtestPlatform.cpp the return value of the function TimeInMillisImplementation from return 1; to return t; which enables timing.
• in UtestPlatform.cpp I declared all the functions except for PlatformSpecificRunTestInASeperateProcess and PlatformSpecificGetWorkingEnvironment as extern "C"
• CppUTest builds with these settings, generating a CppUTest.lib file
• To build the CppUTest tests, I created a new empty Keil project in the root folder of CppUTest, called it CppUTestTest, and made the following changes:
• Target Options->Device Tab->choose "STM32F103VG"
• Target Options->Target Tab->Code Generation->check "Use MicroLib"
• Target Options->Output Tab->Create Executable (not Lib) check "Debug information"
• Target Options->C/C++ Tab->Define->add "STM32F10X_XL,  CPPUTEST_STD_CPP_LIB_DISABLED"
• Target Options->C/C++ Tab->Include Paths->add the CppUTest include directory
• Target Options->C/C++ Tab->Misc Controls->add "--diag_suppress 1300 --diag_suppress 1293  --exceptions"
• Added the include path to the Standard Peripheral Library from STMicroelectronics
• Added the include path to the ARMCC standard implementations
• Target Options->Linker Tab->Misc Controls->add "--vfemode=off"
• Target Options->Debug Tab->check "Use Simulator"
• Target Options->Debug Tab->create a map.ini file that contains the memory regions with the appropriate permissions
• Target Options->Debug Tab->Parameter->add "-REMAP"
• Add all *.cpp and *.c files in tests\
• Add the startupfile for the core. In my case it is "startup_stm32f103x_xl.s"
• Add the system init file, in my case "system_stm32f10x.c"
  
• Add the previously built CppUTest.lib
• change the file AllTests to be able let the tests run in verbose mode
  int ac_override = 2;
  const char * av_override[] = { "exe", "-v" }; //turn on verbose mode
  return RUN_ALL_TESTS(ac_override, av_override);
• since Keil does not support semihosting straightaway, you need to retarget some functions. A working retarget sample can be found from this website. Basically what must be done is redefining fputc to redirect the debug output over the ARM ITM interface. Something like this:
  #pragma import(__use_no_semihosting_swi)
  #define ECHO_FGETC
  volatile int ITM_RxBuffer=0x5AA55AA5; /* Buffer to transmit data towards debug system. */
  
  struct __FILE { int handle; /* Add whatever you need here */ };
  FILE __stdout;
  FILE __stdin;
  
  int fputc(int ch, FILE *f)
  {
    return (ITM_SendChar((uint32_t)ch));
  }
• Furthermore, a working clock definition is needed. Keil provides an example here.
  

Here we are. With this I had a working CppUTest environment under Keil. Debug output (Test results) can be listed via "View->serial Windows-> debug (printf) viewer". I am going along this street now, creating a custom testdriven project. If you admins think it would be useful to create a UtestPlatform.cpp for Keil let me know, I am happy to share my files.

Andreas

[jatin jain]

hi Andreas,

i was trying to use cpputest the way u told in the above message but i am unable to understand following point

• since Keil does not support semihosting straightaway, you need to retarget some functions. A working retarget sample can be found from this website. Basically what must be done is redefining fputc to redirect the debug output over the ARM ITM interface. Something like this:
  #pragma import(__use_no_semihosting_swi)
  #define ECHO_FGETC
  volatile int ITM_RxBuffer=0x5AA55AA5; /* Buffer to transmit data towards debug system. */
  
  struct __FILE { int handle; /* Add whatever you need here */ };
  FILE __stdout;
  FILE __stdin;
  
  int fputc(int ch, FILE *f) 
  {
    return (ITM_SendChar((uint32_t)ch));
  }

in exactly which file do i need to make these changes....?

[A. Robert S.]

The code would go in UtestPlatform.cpp. Have a look at the TI / cl2000 UtestPlatform.cpp. It has code to write all output into a fixed buffer. You should be able to adjust it as described above. It's a while since I did that one, so I can't give you details right away, but it should get you going.

Robert

[Mat]

Hi Keil Users,

I contributed the src/Platforms/Keil/UtestPlatform.cpp on the CppUTest project (see https://github.com/cpputest/cpputest/commit/eef97799243ca16548aca9a8220c7651419f2e62).

Regards,

Mat

[Guillem Coromina]

Hello everybody and happy New Year,

I know that this post is a bit old but I'll try to see if there is any reply.

Thanks for the guide Andreas, it has been useful to me.

I have an issue: In UtestPlatform.cpp there is the following function:

static int AtExitImplementation(void(*func)(void))

{

    return atexit(func);

}

As the standard library definition is disabled there is no implementation for atexit.

Did anybody have this issue or is something that has come up during the evolution of the project?