K64F, STM32F429: IAR linker scripts dynamic heap fix

[tymoteuszblochmobica]

Description

IAR icf linker scripts modified to use dynamic heap allocation of all available memory.
Modified targets
STM32F429
K64F

Pull request type

[ ] Fix
[ ] Refactor
[x] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

@kjbracey-arm
@juhhei01
@teetak01
@juhoeskeli

Release Notes

[ciarmcom]

@tymoteuszblochmobica, thank you for your changes.
@teetak01 @maclobdell @kjbracey-arm @juhhei01 @MarceloSalazar @ARMmbed/mbed-os-maintainers please review.

[juhhei01]

Looks good. Is it this generic change which is not tied to specific IAR version? If it is I like a lot. I try to google that with expanding size and did not found any matching content than GitHub mbedos #8306.

[teetak01]

Looks good. Should this be done for all targets?

[kjbracey]

@deepikabhavnani was working on this for all targets. Can't quite follow where that work reached. This was PR reverting it?

#9432

Earlier version: #9205

It does require IAR 8, but IAR 7 is not officially supported any more.

[kjbracey]

I'd like to see it done for all targets, but don't have a particular problem with doing it piecemeal for a board that needs the memory now for some test, if there's no resource to do the full systematic sweep.

Another memory thing that came to my attention recently is having static prioritisation correct in ARM builds for split memory devices like K64F - it should have .ANY2 in its small 64K region and .ANY1 in its 192K region to prioritise putting static data in the first area, leaving more space in the second area for heap. Without that, ARM prioritises the bigger area.

If you don't fill the small area, spare space there goes totally wasted. Heap won't use it. (Only GCC retarget has split heap support at the moment).

How does IAR handle its two DATA regions? Will it fill the small one first?

[kjbracey]

Also for K64F, it doesn't have the GCC split heap addition. Unlike IAR+ARM, the first 64K can't be used for static data in GCC, because it can't auto-distribute it between regions, but you could use it for a second heap area. You'd need to turn on MBED_SPLIT_HEAP - check the (few) other targets defining that.

[bulislaw]

We already have couple of boards with the expanding heap.

[0xc0170]

@deepikabhavnani was working on this for all targets. Can't quite follow where that work reached. This was PR reverting it?

cc @ARMmbed/mbed-os-core

[tymoteuszblochmobica]

This PR is to fix following problems for STM32F429 and K64F target
https://jira.arm.com/browse/IOTCORE-404
https://jira.arm.com/browse/IOTCORE-1218
Im not familiar why @deepikabhavnani PR #9432 reverts her previous commits for dynamic heap.

[deepikabhavnani]

Dynamic heap support was the needed feature as other toolchains do support it, it was done as part of compiler upgraded by management decision was not to have breaking changes in same release as compiler update. Plan was to un-revert that commit in next minor release.

[evedon]

I'd like to see it done for all targets, but don't have a particular problem with doing it piecemeal for a board that needs the memory now for some test, if there's no resource to do the full systematic sweep.

I will create a task in the backlog to do the same for all targets.

[kjbracey]

It would be worth incorporating my points about GCC split heap and ARMC6 (and IAR?) region prioritization into the same issue. Those will only be relevant to targets with split memory maps like the K64F, but for those, there may be an easy memory gain to get.

For K64F, all tools are currently wasting memory for different reasons, so it's kind of a no-score draw. This fix on its own would leave IAR 60-or-so KiB ahead of GCC and ARM.

[0xc0170]

CI started

[mbed-ci]

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 1
Build artifacts