Fix initialisation sequence of RTC

[mjh65]

Initialisation of RTC was wrong for boot from sysreset, and resulted
in RTOS with nothing to do in its main thread. This fixes the bug.

Summary of changes

Impact of changes

Migration actions required

Documentation

---

Pull request type

[] 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)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

Reviewers

---

[0xc0170]

As this is quite old platform, this should be functional as it was. What bug is this fixing?

[0xc0170]

why this order would matter? I would assume it should work either way (the 3 functions below are just setting nvic and interrupt.

[mjh65]

I'm developing software for a MAX32630, and I was finding that the software ran as expected from a POR/power-cycle, but would never reach main() when I was using the DAPlink debugger. So I spent some time investigating this, and found that the init_rtc() function was also never reached. When the NVIC IRQ was enabled the ISR would fire, and never returned.
(Although I didn't debug this part in detail, I assume that instead of a normal return from the IRQ, this is being used to pass control to the RTOS scheduler. But in this case the main() function has not yet been added to the queue, so there is nothing to do, and the system is deadlocked.)
The reason for the difference in behaviour between POR and DAPlink debugger appears to be that the debugger issues a SYSRESET, and the RTC survives the SYSRESET. The RTC continues to generate interrupt conditions while the debugger is flashing the device and starting up.
I was able to resolve the problem by moving the call to init_rtc() to the start of lp_ticker_init(), after which I found that the breakpoint on main() would be hit as expected when using the debugger. The setup in init_rtc() puts the module into a safe state so that the NVIC interrupt can be enabled without being immediately triggered. There is no difference to the POR behaviour.
Our project is using a fork of the Mbed repo. Unfortunately I don't have time to run all of the Mbed test suites, but I thought I would offer this fix to the main project. As mentioned, this is an old device, and the issue would only affect use with a debugger, or reset due to watchdog or software trigger. Maybe these scenarios are not covered in testing, and have not been used in real projects?

[ozersa]

@mjh65 Thank you very much for your effort and contribution, As Maxim (Now part of ADI) we appreciate it.
Please let us think on it and run related test suites.
Regards.

[0xc0170]

@ozersa Any update, did the tests fail?

[ozersa]

Related test suites passed for GCC_ARM. The change request is fine.
GCC_ARM_TestResult_For_PR_15184.txt

@mjh65 thanks for your contribution.

[ciarmcom]

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

[0xc0170]

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_build-cloud-example-ARM	✔️
jenkins-ci/mbed-os-ci_unittests	✔️
jenkins-ci/mbed-os-ci_build-cloud-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_build-greentea-ARM	✔️
jenkins-ci/mbed-os-ci_build-example-ARM	✔️
jenkins-ci/mbed-os-ci_build-greentea-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_build-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_greentea-test	✔️

[mergify]

This PR does not contain release version label after merging.