Adjust STMF411xE IAR linker file to mbed-os memory needs.

[KariHaapalehto]

Description

mbed cloud client needs more heap, so heap size increased.
8k is enough for stack, so stack size decreased.
New linker file configuration tested with HW, mbed cloud client is able to register to cloud

Pull request type

[X] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Breaking change

[0xc0170]

There's alignment for stack to be 1k @mprse please confirm

[mprse]

I confirm, stack size should be 1k.

[0xc0170]

Please fix the stack size

[KariHaapalehto]

Stack size changed

[cmonr]

@KariHaapalehto Why is the PR change so specific? A single target against a single compiler?

Also, is this required for 5.10?

[KariHaapalehto]

@cmonr This error only occur with IAR 7.x compiler, since it isn't supporting dynamic heap. This correction has been done already to stm32f439xx_flash.icf and it might be be good idea to check also other target in separate PR. Cloud client isn't working without this change, so it would be good to have in 5.10

[kjbracey]

This is covering same area as #7238, and is not inconsistent with it. That's covering multiple targets, but appears to be not fully complete, and doesn't currently touch this one.

[jeromecoutant]

So @kjbracey-arm ,
you suggest to close this PR and make #7238 complete (all targets, all toolchain update)?

[kjbracey]

If this is urgently needed for 5.10 because it's a key cloud client target, I'd say it can go now, and other platforms can get mopped up by #7238 during 5.11. (Although that is only covering stack sizes, not the additional heap size increase here.)

This error only occur with IAR 7.x compiler

BTW @KariHaapalehto - are you suggesting IAR 8 does have dynamic heap? Would be good news if true.

[adbridge]

Looks like we should definitely get this one in for RC2 especially as #7238 will not come in until 5.11 by the looks of it.

[cmonr]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 3046
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/7909/

Triggering tests

/morph test
/morph export-build
/morph mbed2-build

[mbed-ci]

Exporter Build : SUCCESS

Build number : 2662
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/7909/

[mbed-ci]

Test : FAILURE

Build number : 2819
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/7909/2819

[cmonr]

Test CI needs to be restarted. Will restart aftetr 5.10-rc2 is generated.

We had to cutoff RC2 to continue testing with new fixes. Still planning on getting this into 5.10.

[cmonr]

/morph test

[mbed-ci]

Test : SUCCESS

Build number : 2822
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/7909/2822

[cmonr]

Would prefer for that heap size change to be tied to the application instead of making the change on the target itself, but I don't think we have that kind of mechanism to facilitate that.

@mprse @kjbracey-arm @ARMmbed/team-st-mcd Final thoughts/OKs?