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

Improve the startup code on the STM32F070 #4525

Merged
merged 3 commits into from Jul 10, 2017

Conversation

Projects
None yet
7 participants
@fahhem
Contributor

fahhem commented Jun 12, 2017

Description

This reduces the number of loads inside of the .data copy loop by 3 by using one more register. It should work on any STM32 with at least 5 general-purpose registers. If only 4 are available, then 1 load could still be removed from the original implementation.

Status

READY

Migrations

NO

Steps to test or reproduce

Run any program with a non-empty .data section (globals, for instance).

fahhem added some commits Jun 12, 2017

Improve the startup code on the STM32F070
This reduces the number of loads inside of the .data copy loop by 3 by using one more register. It should work on any STM32 with at least 5 general-purpose registers. If only 4 are available, then 1 load could still be removed from the original implementation.
@0xc0170

This comment has been minimized.

Member

0xc0170 commented Jun 12, 2017

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Jun 12, 2017

retest uvisor

@fahhem

This comment has been minimized.

Contributor

fahhem commented Jun 12, 2017

I don't have the ability to do that, nor can I even see the details

@LMESTM

This comment has been minimized.

Contributor

LMESTM commented Jun 13, 2017

@fahhem Hello - have you developed this code from scratch in the context of MBED or has this already been exercised before in another context ?

@fahhem

This comment has been minimized.

Contributor

fahhem commented Jun 13, 2017

@bcostm

This comment has been minimized.

Contributor

bcostm commented Jun 13, 2017

ST_INTERNAL_REF 34824

@theotherjimmy

This comment has been minimized.

Contributor

theotherjimmy commented Jun 19, 2017

@bcostm Will you be updating this in the ST SDK? Should we close this PR?

@bcostm

This comment has been minimized.

Contributor

bcostm commented Jun 20, 2017

We are going to launch some tests first and we'll let you know if ok to merge.

@jeromecoutant

This comment has been minimized.

Contributor

jeromecoutant commented Jun 22, 2017

All tests are OK
Thx @fahhem

@fahhem

This comment has been minimized.

Contributor

fahhem commented Jun 22, 2017

Glad I could help!

@0xc0170 0xc0170 added needs: CI and removed needs: review labels Jun 22, 2017

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Jun 22, 2017

CLA checked, signed ;) Waiting for CI

@theotherjimmy

This comment has been minimized.

Contributor

theotherjimmy commented Jun 26, 2017

/morph test

@mbed-bot

This comment has been minimized.

mbed-bot commented Jun 27, 2017

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 645

Test failed!

@fahhem

This comment has been minimized.

Contributor

fahhem commented Jun 27, 2017

That looks like it failed due to a totally untouched processor timing out, so it seems like it's just flaky? http://mbedosci.cloudapp.net/results/pr/4525/645/FAIL/NCS36510/IAR/test_report_NCS36510-IAR.html

@theotherjimmy

This comment has been minimized.

Contributor

theotherjimmy commented Jun 29, 2017

/morph test

@mbed-bot

This comment has been minimized.

mbed-bot commented Jun 29, 2017

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 692

Test failed!

@fahhem

This comment has been minimized.

Contributor

fahhem commented Jun 30, 2017

Seems like it's another different board that's failing. Is morph normally this flaky?

@jeromecoutant

This comment has been minimized.

Contributor

jeromecoutant commented Jul 7, 2017

/morph test

@theotherjimmy

This comment has been minimized.

Contributor

theotherjimmy commented Jul 7, 2017

Ah, we limit the users who can trigger our CI. We don't want it DDOSed after all. Let me get that for you.

/morph test

@fahhem

This comment has been minimized.

Contributor

fahhem commented Jul 7, 2017

Is it normal for the CI to be this flaky?

@theotherjimmy

This comment has been minimized.

Contributor

theotherjimmy commented Jul 7, 2017

Nope. We just merged a few robustness improvements for the CI. I think this run should be more stable.

@theotherjimmy

This comment has been minimized.

Contributor

theotherjimmy commented Jul 7, 2017

retest uvisor

@theotherjimmy

This comment has been minimized.

Contributor

theotherjimmy commented Jul 7, 2017

It failed to update the status :(

@mbed-bot

This comment has been minimized.

mbed-bot commented Jul 8, 2017

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 749

All builds and test passed!

@fahhem

This comment has been minimized.

Contributor

fahhem commented Jul 8, 2017

Looks like ram usage went up since the last release for stm32 boards, but not just this one.

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Jul 10, 2017

Looks like ram usage went up since the last release for stm32 boards, but not just this one.

Can you elaborate?

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Jul 10, 2017

retest uvisor

@theotherjimmy theotherjimmy merged commit b38c85c into ARMmbed:master Jul 10, 2017

4 checks passed

Cam-CI uvisor Build & Test Success
Details
ci/morph-test Job has completed
Details
continuous-integration/jenkins/pr-head This commit looks good
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@fahhem fahhem deleted the fahhem:patch-1 branch Jul 12, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment