Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent heap sizes between toolchains, especially IAR #3466

Closed
kuggenhoffen opened this issue Dec 19, 2016 · 9 comments
Closed

Inconsistent heap sizes between toolchains, especially IAR #3466

kuggenhoffen opened this issue Dec 19, 2016 · 9 comments

Comments

@kuggenhoffen
Copy link
Contributor

Description

  • Type: Bug
  • Priority: Major

Bug

Target
K64F

Toolchain:
IAR

Toolchain version:
7.80.2.11975

mbed-cli version:
1.0.0

meed-os sha:
a1c0840 (HEAD, tag: mbed_lib_rev129, tag: mbed-os-5.2.2) Merge pull request #3227 from ARMmbed/release-candidate

Expected behavior
I would expect available heap amount to be somewhat similar between all the toolchains to guarantee compatibility. Currently it seems that the available heap is very different in IAR (~65k) compared to ARMCC (~180k) or GCC (~175k)

Actual behavior
IAR heap size seems to be fixed at ~65k

Steps to reproduce
Numbers above were determined with following code on K64F with serial terminal:

#include "mbed.h"

RawSerial   pc(USBTX, USBRX);

static void heap_loop_check(int maxSize, int total)
{
    pc.printf("Next try: %d, total so far: %d\r\n", maxSize, total);
    for(int n = maxSize; n >= 0; n--){
        if(n == 0){
            pc.printf("Available heap: %d\r\n", total);
            break;
        }
        void *block;
        block = malloc(n);
        if (!block) {
          continue;
        }
        heap_loop_check(n, total + n);
        free(block);
        break;
    }
}

int main() {
    pc.baud(115200);
    heap_loop_check(80000, 0);
}
@0xc0170
Copy link
Contributor

0xc0170 commented Dec 19, 2016

@c1728p9 Didn't we unified the heap sizes? I can't find the patch.

As I recall it used to be that IAR requires a fixed heap size, and the rest toolchains are flexible (allowing heap to grow).

@c1728p9
Copy link
Contributor

c1728p9 commented Dec 19, 2016

With ARM and GCC_ARM the heap takes up all remaining free RAM space. The IAR heap is a fixed, hardcoded size due to toolchain limitations.

@kuggenhoffen
Copy link
Contributor Author

How do I increase heap size for application? I can modify the linker file but is there a compatible way that will work for all targets and toolchains as well as is somehow portable for an application?

@kuggenhoffen
Copy link
Contributor Author

Also GCC reports allocated heap as 65k when it actually allocated over 100k more, which is a bit misleading.

@0xc0170
Copy link
Contributor

0xc0170 commented Dec 22, 2016

How do I increase heap size for application? I can modify the linker file but is there a compatible way that will work for all targets and toolchains as well as is somehow portable for an application?

Currently not, defined in the linker script per toolchain (IAR has it predefined, others remaining space used).

@c1728p9 Is this documented anywhere? We might consider having it in the Handbook

@c1728p9
Copy link
Contributor

c1728p9 commented Dec 22, 2016

I think the only info we have on this is here:
https://github.com/ARMmbed/Handbook/blob/master/docs/concepts/memory_model.md

Ideally we would get IAR to match everything else so these problems wouldn't occur in the first place.

@yogpan01
Copy link
Contributor

@c1728p9 @0xc0170 any updates on this ? Do we have a solution for fixed Heap problem for IAR ?

@c1728p9
Copy link
Contributor

c1728p9 commented Jan 19, 2017

Last I heard, IAR had no intention of making their allocator dynamically sizable. @sg- have you heard anything new from them?

@ghost
Copy link

ghost commented Oct 27, 2017

GitHib issue review: Closed due to inactivity. Please re-file if critical issues found.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants