Skip to content

Configure heap size in IAR build #8306

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

Closed
andresag01 opened this issue Oct 2, 2018 · 14 comments
Closed

Configure heap size in IAR build #8306

andresag01 opened this issue Oct 2, 2018 · 14 comments

Comments

@andresag01
Copy link

andresag01 commented Oct 2, 2018

Description

We are currently reworking one of our example applications which we regularly test in several targets with IAR, ARMCC and GCC_ARM. However, one of our tests keeps failing with a heap out-of-memory error for KW24D and IAR (for reference, the failure logs are here). I looked around online (as I do not actually have access to the board or compiler) and I think that the problem is most likely due to the fixed heap size that IAR requires setting at compile time. I understand that the allocator used by this toolchain has some limitations, which (I suppose) we have to accept. Some related tickets:

Taking a quick look at the IAR linker script for KW24D, it looks to me that the default size is set to 16KB, which is probably insufficient for the application we are working with. Specially considering the fact that the target has 64KB RAM (I think) and static data only takes about 9KB.

With this in mind, is it possible to configure the heap size at compile time (or runtime!) using the build system or some public API? For example, I think there is a similar option for stack: MBED_CONF_RTOS_MAIN_THREAD_STACK_SIZE and MBED_CONF_APP_MAIN_STACK_SIZE. It would be ideal to have something similar to configure the heap size for systems with limitations like IAR.

Note: I think an alternative solution would be to simply increase the heap size value in the linker script, but I am not sure what would be a sensible value that would not break other applications. IMHO, there probably isn't a one-size-fits-all value...

Issue request type

[x] Question
[ ] Enhancement
[ ] Bug

@andresag01
Copy link
Author

andresag01 commented Oct 8, 2018

@cmonr @0xc0170: Any ideas? Thanks!

@cmonr
Copy link
Contributor

cmonr commented Oct 8, 2018

Hmmm, that is an interesting one.
Thanks for the referenced issues, looks like we've let this bug drag along since before I was even with ARM.

@c1728p9 @theotherjimmy @bridadan Would y'all have any ideas since this appears to be related to a really old issue(s)?

@bridadan
Copy link
Contributor

Not sure, it might be as simple as increasing the value in the linker script. Though I think someone more familiar with this platform should do the tweaking (@maclobdell any ideas?).

As far as the static heap size for IAR, @deepikabhavnani and @c1728p9 I think were pretty familiar with the issue

@deepikabhavnani
Copy link

This issue is dragged as we were anticipating IAR 8.x integration earlier and in background we are planning to have auto-generated linker scripts, but all that will take long. For now best is to increase it in linker script.

@ciarmcom
Copy link
Member

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-224

@SeppoTakalo
Copy link
Contributor

Any progress on this?

IAR is now updated to 8.32, does it improve the situation at all?

@michalpasztamobica
Copy link
Contributor

I don't quite understand why this issue is closed.
Looking at an icf script for a random architecture, I can see that heap is still fixed-size.

@0xc0170
Copy link
Contributor

0xc0170 commented Apr 18, 2019

I've noticed few issues closed yesterday without reason, will be fixed (either reopen or reason provided)

cc @linlingao ^^

@linlingao
Copy link
Contributor

Accidentally closed by script. Reopen.

@linlingao
Copy link
Contributor

@andresag01 Please have a look at this implementation:
https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/TARGET_STM32L4/TARGET_STM32L475xG/device/TOOLCHAIN_IAR/stm32l475xx.icf

This should answer your question. Please reopen if you have further questions.

@andresag01
Copy link
Author

@linlingao: Could you please explain how the file you linked for the STM device (that we do not even use in our examples) addresses the problem raised in this ticket?

Please note that I am not an expert on how the dynamic memory handling is set up in Mbed OS, but as far as I can see the heap size is still hard-coded here:

define symbol __size_heap__   = 0x10000;
define block CSTACK    with alignment = 8, size = __size_cstack__   { };
define block HEAP      with expanding size, alignment = 8, minimum size = __size_heap__     { };

This should answer your question. Please reopen if you have further questions.

I do not feel that my question has been fully answered. Also, please note that I cannot reopen this ticket (probably because I am not an Mbed OS maintainer).

@linlingao
Copy link
Contributor

Prior to IAR8, the HEAP block is fixed in size. We've released IAR8 support. One of the nice features in IAR8 is this dynamic heap configuration. The 0x10000 is the minimum size. You can change it to any value you see fit. The HEAP can be expanded to what's left in RAM, just like how ARM compiler and GCC_ARM place the HEAP block.

@andresag01
Copy link
Author

Thanks for the explanation. When you say:

The HEAP can be expanded to what's left in RAM...

Does that mean that it "can" and we are CURRENTLY taking advantage of this without any changes to the linker scripts or existing applications? Does that apply to any IAR target? Are we no longer supporting any IAR versions prior to IAR8?

@linlingao
Copy link
Contributor

I see some targets are taking advantage of this feature, some targets are not. Our silicon partners need to make the changes in linker scripts to take advantage of this feature.
We officially no longer support IAR7. IAR7 may still build on some targets, but we no longer maintain it.

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

No branches or pull requests

10 participants