-
Notifications
You must be signed in to change notification settings - Fork 3k
Enable split heap in K64F/K66F devices #10950
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
Enable split heap in K64F/K66F devices #10950
Conversation
-Enable MBED_SPLIT_HEAP for K64F and K66F -Allow GCC_ARM toolchain to utilize remaining 64K memory area -Make ARM toolchain to start memory filling from 64K region to leave more space to bigger 192K region.
CI started. |
Test run: FAILEDSummary: 1 of 4 test jobs failed Failed test jobs:
|
ARM build failed: |
When packing data into multiple regions using the `.ANY` directive, the linker can accidentally overfill an area. This doesn't normally happen because it defaults to `--any_placement=worst_fit`, which puts data in the region with most space. When we prioritise regions with `.ANY1`/`.ANY2`, it may totally fill an area, then fail to leave enough space for linker-generated veneers. We've just seen this error with the new K64F linker map. Adding `--any-contingency` makes it lower priority when a region is 98% full, avoiding this error. The option should not have any effect on targets with scatter files without prioritised `.ANY` directives.
Fix provided, CI started. |
Test run: FAILEDSummary: 2 of 11 test jobs failed Failed test jobs:
|
Linker still reports a problem |
Move heap_0 after .data as it is also placed to m_data.
CI started |
Test run: SUCCESSSummary: 11 of 11 test jobs passed |
Description
-Enable MBED_SPLIT_HEAP for K64F and K66F
-Allow GCC_ARM toolchain to utilize remaining 64K memory area
-Make ARM toolchain to start memory filling from 64K region to leave
more space to bigger 192K region
Pull request type
Reviewers
Release Notes