Error 129 mapmem map size truncated to 128mb

to cppu…@googlegroups.com

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:

STM32F103VGI 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 srcCppUTest
• Added srcPlatformsIarUtestPlatform.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

to cppu…@googlegroups.com

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

to cppu…@googlegroups.com

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

Erick

to cppu…@googlegroups.com

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

to cppu…@googlegroups.com

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:KeilARMARMCCinclude (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

to cppu…@googlegroups.com

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

to cppu…@googlegroups.com

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

to cppu…@googlegroups.com

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

unread,

to cppu…@googlegroups.com

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?)?

to cppu…@googlegroups.com

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

to cppu…@googlegroups.com

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

to cppu…@googlegroups.com

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?

to cppu…@googlegroups.com

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?

to cppu…@googlegroups.com

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

to cppu…@googlegroups.com

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

to cppu…@googlegroups.com

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…

to cppu…@googlegroups.com

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

unread,

to cppu…@googlegroups.com

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.

to cppu…@googlegroups.com

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

to cppu…@googlegroups.com

Hi Erick,

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

to cppu…@googlegroups.com

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

to cppu…@googlegroups.com

to cppu…@googlegroups.com

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

to cppu…@googlegroups.com

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

to cppu…@googlegroups.com

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

to cppu…@googlegroups.com

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

to cppu…@googlegroups.com

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

to cppu…@googlegroups.com

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

to cppu…@googlegroups.com

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

to cppu…@googlegroups.com

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 написал:

to cppu…@googlegroups.com

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

unread,

Vitaliy Bortsov

unread,

to cppu…@googlegroups.com

Hi Vitaliy,

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

Regards
Stefan

to cppu…@googlegroups.com

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

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:

STM32F103VGI 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 srcCppUTest
• Added srcPlatformsIarUtestPlatform.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

to cppu…@googlegroups.com

to cppu…@googlegroups.com

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

unread,

to cpputest

Hello everybody and happy New Year,

• Forum
• Input and Assistance
• Support Q&A
• Technical mapmem.cpp crash at random times.

1. 

   
   Member
   

   ---

   Hello there,

   I’ve been always having a problem with that error. At random times, mostly on northend, I get this error a lot. I’ve been searching for a solution here and there and found that:

   http://forum.warmane.com/showthread.php?t=331321

   Although the guy over there had a different error, if I use that program (Large Address Aware) and choose the mapmem.cpp file, will it have the same effect? Will it fix the problem? Or is it another solution regarding this one?

   ---

2. 

   
   Member
   

   ---

   It’s the same category of errors.
   You can’t use it on that file (you don’t have that .cpp file), you need to use it on your wow.exe.
   Cant promise it will fix it completely, but it should appear less often with the LAA fix.

   ---

3. 

   
   Member
   

   ---

   I had the same error as you do (mapmem.cpp crash) and it solved my problem, got no errors now, so you should give it a try.

   ---

4. 

   
   Forum Veteran
   

   ---

   if I use that program (Large Address Aware) and choose the mapmem.cpp file, will it have the same effect?

   Use the Program «Large adress aware» on your WoW file, It fixes memory crashes in wow, a lot of times when your game crash it’s because wow takes up more memory then it’s «allowed» to, «large adress aware» increases the memory WoW can take from 2gb to 4gb (I think thats correct)
   Usually when you mod your game a lot (addons, patches etc) it causes crashes in memory because WoW wants to use more then the standard set.

   ---

5. 

   
   Member
   

   ---

   Did it, but it seems like nothing for fixed at all :/

   ---

6. 

   
   Member
   

   ---

   Hi, I’ve got same problem. Have you handle it?

   ---

Posting Permissions