KDS build code size greater than IAR EWARM

[isaotakashima]

We want to use the Kinetis Design Studio (KDS) instead of the IAR EWARM.

However the code size that was build by KDS greater than code size that was build by IAR EWARM.

Here is summary of code size that was build by KDS and EWARM.

KDS optimize option	read only code	read only data	total of read only	read write data
O0	7892	680	8572	2776
O1	6108	680	6788	2776
O2	6264	680	6944	2776
O3	7744	680	8424	2776
Os	5352	680	6032	2776
Ofast	7744	680	8424	2776
Og	5924	680	6604	2776

EWARM optimize	read only code	read only data	total of read only	read write data
None	4324	816	5140	12
Low	4080	816	4896	12
Middle	4144	208	4352	12
High Size	3912	208	4120	12
High Speed	5214	208	5422	12
High Balance	4316	208	4524	12
High Speed no limit	4302	208	4510	12

I check and compare both .map file, I find out a reason why code size that was build by KDS greater than EWARM.

KDS was link the library then increase 1,760 bytes in read only code section, increase 672 bytes in read only data and increase 712 bytes (exclusion stack and heap) in read write data.

Can we remove library to reduce code size?

I attached my project.

Please advise to solve this issue as soon as possible.

Best regards,

Takashima

Original Attachment has been moved to: KE06_LED_demo.zip

[BlackNight]

Hello Takashima,

As initial comment: KDS is a free toolchain, based on open source gcc, and there is no point that this toolchain is intended to be best in class for code size and code speed: this  is why there are commercial tools like IAR, and this is why they have a price tag attached to it. Regardless, code size/density is heavily influenced by coding style and especially library usage. And what kind of startup code is used. I'm not sure if you used the same startup code (or sequence) for IAR too?

In my experience GNU gcc is in the +10% range compared to commerical compilers. So if you have to fight for every singly code (or data) byte, then you will need either to fine tune your sources, or go with commercial tools.

There is one easy point to get your numbers down: switch to a later gcc toolchain. I have run your application with the launchpad 2014 q3 (with -specs=nano.specs -specs=nosys.specs linker options, see Switching ARM GNU Tool Chain and Libraries in Kinetis Design Studio | MCU on Eclipse).

I see that you have 1 KByte stack and heap size allocated. You need 1 KByte of heap for the KDS original toolchain, but with the launchpad you do not need this (see Switching ARM GNU Tool Chain and Libraries in Kinetis Design Studio | MCU on Eclipse). You might need to verify this with your board (I don't have your board available).

With -O1:

text	data	bss	dec	hex    filename
5128	108	300	5536	15a0    KE06_LED_demo.elf

which is much less than what you have.

With -Os:

text	data	bss	dec	hex    filename
4332	108	300	4740	1284    KE06_LED_demo.elf

which is close to what you have with IAR.

Best regards,

Erich

[isaotakashima]

Dear Erich,

Thank you for your reply. I also got same result if use the launchpad 2014 q3 (gcc-arm-none-eabi-4_8-2014q3-20140805-win32.zip (md5)).

I would like to make sure below items.

1. Switching ARM GNU Tool Chain

I was switched ARM GNU Tool Chain refer the "Switching ARM GNU Tool Chain and Libraries in Kinetis Design Studio".

But I have the following error.

Cannot run program "make": Launching failed

Then I copied original "make.exe" to new \toolchain\bin folder.

Is it OK?

2. Which GNU Tool Chain do you recommend?

Currently we can download "4.9-2014-q4-major release from the 4.9 series released 2014-12-10 (gcc-arm-none-eabi-4_9-2014q4-20141203-win32.zip (md5))".

I use this latest version, text (rom code) size was little bit increased.

I believe that we should use latest version.

Please let us know which GNU Tool Chain do you recommend.

Please reply as soon as possible.

Best regards,

Takashima

[BlackNight]

Dear Takashima,

1) That's ok. It depends on your path settings, but to copy the make utility is fine.

2) I have downloaded the 4.9 q4 2014 release too, and I noticed as well that code size increase. Additionally, 4.9 is very new, and in the past sometimes it took a follow up release (in Q1) to fix bugs.

I have not used the 4.9 much, and not found any issues so far, but for now I stick with the 4.8 q3 release, probably until mid of next year.

Given that code size increase I see on my side too, and the risks, it is probably better if you go with 4.8 q3 too. But it is really up to you.

Erich