MQX library sizes after porting to MQX4.2

[lh_dan]

I have a completed firmware project on a K61 the used CW10.6 and MQX4.0 (bsp, psp, rtcs, & shell). The Freescale compiler (C++) was used on this project. A new version of the firmware has been requested and along with new features I was hoping to port the project to use MQX4.2 and the GCC compiler. After finishing the port I was surprised to find that the file size had increased considerably.  A debug version increased from 0x98CD0 to no longer being able to fit in 1M of Flash space and a release version (optimized for size -Os) increased from 0x82790 to 0x9E580.

I noticed that the file size of the MQX libraries (.a files) had also got quite large for my projects.

I took the base projects for the MQX k70 examples (twrk_70f120m) and rebuilt them and found similar file increases.  Debug builds of the MQX BSP library increased from 2,926k in MQX4.0.0 to 106,218k in MQX4.2.0. Debug builds of the MQX PSP library increased from 2,158k in MQX4.0.0 to 75,046k in MQX4.2.0.

Is this to be expected with a port to MQX4.2? Are there any other optimizations that can be made to reduce the sizes of the MQX libraries?

-Dan

[lh_dan]

I figured out one of my issues. When porting the lcf file as defined in section 5.8 of MCU_Kinetis_GCC.pdf, I incorrectly implemented both options for the INCLUDE command.  This resulted in the bootloader binary being placed in the bootloader section and in data ram. After fixing this my GCC debug build is now 0xd7ce0 and my GCC release build is 0x76550 (actually smaller, cool!). So now I guess my question is if the debug build is expected to be this much larger than the release build and is there any way to decrease the size of the debug build. I still believe that the debug build is useful when using the debugger.

[soledad]

Hello Daniel,

Thank you for your contribution.

CodeWarrior development environment enables you to have multiple build configurations, called build targets. All projects in the Freescale MQX RTOS contain at least two build targets:

• Debug target - Compiler optimizations are set low to enable easy debugging.

• Release target - Compiler optimizations are set to maximum, to achieve the smallest code size and fast execution. The resulting code is very hard to debug.

The difference between Release mode and Debug mode, is in Debug mode there will be debug information added into the executable. These debug information has no impact on performance.

You can build your application with optimization level O3 and still have debug information.

Please check the discussion about debug and release mode in CW in the next thread.

http://mcuoneclipse.com/2012/06/01/debug-vs-release/

Have a great day,
Sol

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[lh_dan]

soledad,

Thank you for your response. I always knew that I could play with the optimization levels in order to get a smaller image and I will probably have to take I look at that as I add more features to my build. You say that I should be able to use optimization level 3 (-O3) and still retain full debugging capabilities? This would be great if it is true. I tried using the debugger at the default release level (-Os) and it proved to be impossible to step through the code.

I was hoping to find out why the size ballooned so much between the Freescale and GCC compiler at the default debug level (-O0) and wondering if there were compiler options that could improve this. But maybe it doesn't matter if the debugger still works with some level of optimization.

-Dan