STM32: remove critical sections in flash_program_page

[jeromecoutant]

Summary of changes

Hi

There was no real issue for now to have introduced critical sections in flash_program_page function.
And this has introduced at least 2 new issues:

• STM32F7 flash driver disables interrupts unnecessarily #14058
• FLASHIAP test failure for DISCO_L562QE

NB: critical sections introduction in flash_erase_sector was due to #13792

@ARMmbed/team-st-mcd

Impact of changes

Migration actions required

Documentation

---

Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

Reviewers

---

[ciarmcom]

@jeromecoutant, thank you for your changes.
@ARMmbed/mbed-os-maintainers please review.

[kjbracey]

The #14058 issue is the same for both write and erase, and I would expect the same answer should apply to both - flash usually acts the same way for write-in-progress and erase-in-progress.

This on its own would not fix #14058.

[0xc0170]

NB: critical sections introduction in flash_erase_sector was due to #13792

Is this needed still ? As noted, if program writing does not have it, why erase has it?

[jeromecoutant]

Is this needed still ? As noted, if program writing does not have it, why erase has it?

Yes, for me first patch has solved the issue.

[0xc0170]

This on its own would not fix #14058.

I was asking about this - how to fix this issue completely ?

[jeromecoutant]

This on its own would not fix #14058.

I was asking about this - how to fix this issue completely ?

Yes, I removed the github link between this PR and #14058
Issue will stay as opened after this PR merge.

[kjbracey]

I was asking about this - how to fix this issue completely ?

I would have expected removing the critical sections from the erase to be the answer.

What was the logic for adding them as a solution for #13792? I see the claim that it fixed it, but I don't see the reasoning for attempting it as a fix in the first place.

[0xc0170]

@jeromecoutant please review above question

[jeromecoutant]

Yes, more work is needed on this topic.
That's why I removed the link with #14058
I think this PR is needed for short term:

• solves L5 issue
• keep first solution in NUCLEO_F429ZI hangs during flash erase #13792 that was indicated as OK

[adbridge]

CI started

[mbed-ci]

Jenkins CI Test : ✔️ SUCCESS

Build Number: 1 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs	Status
jenkins-ci/mbed-os-ci_unittests	✔️
jenkins-ci/mbed-os-ci_build-greentea-ARM	✔️
jenkins-ci/mbed-os-ci_cmake-example-ARM	✔️
jenkins-ci/mbed-os-ci_build-greentea-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_cmake-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_build-example-ARM	✔️
jenkins-ci/mbed-os-ci_cmake-cloud-example-ARM	✔️
jenkins-ci/mbed-os-ci_build-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_build-cloud-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_cmake-cloud-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_build-cloud-example-ARM	✔️
jenkins-ci/mbed-os-ci_cmake-example-test	✔️
jenkins-ci/mbed-os-ci_greentea-test	✔️

[0xc0170]

I'll merge and keep the issue opened so it can be tracked and fix properly.