ST boards: Fix sleep tracing

[hugueskamba]

Summary of changes

Prevent singleton lock if the RTOS is not yet ready.

lp_ticker is used during the RTOS initialization process.
ST lp_ticker implementation calls sleep functions
which in turn attempts to print to the console when sleep tracing
is enabled. Console initialization attempts to lock the singleton mutex.

fixes #11497
fixes #12593

To test:

1. Clone mbed-os-example-blinky.
2. Build, program, and open a serial terminal with: mbed compile -t <TOOLCHAIN> -m <ST_TARGET> -f --sterm -DMBED_SLEEP_TRACING_ENABLED.
3. Sleep tracing is enabled (and printing on the console), the board does not reboot.

Impact of changes

Sleep tracing can be enabled with ST boards.

Migration actions required

N/A

Documentation

N/A

---

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

@kjbracey-arm @c1728p9 @korjaa @LMESTM @evedon

---

[0xc0170]

if we remove usage of singleton_mutex_id in this file, then does it still need to be in mbed rtos start ? it is defined there and initialized but not used. Only used here in this file.

Good to have these issues fixed!

[kjbracey]

I'm a bit wary of this - osKernelGetState is a much heavier operation than reading a variable. But on the other hand, singleton_lock is only normally used after an atomic check, I think.

But what is the actual problem with the original code? I still don't understand the failure mode from our discussion. Is singleton_mutex_id getting set before the kernel is started?

[kjbracey]

Another possibility along the same lines - how about if the crashy thing we put into the mutex error callback chose not to crash if the kernel isn't running?

That would have the general effect of Mutex::lock and Mutex::unlock quietly doing nothing while called in weird situations.

Maybe that would cover up too much. But the main thing we were trying to catch with the crash was the "call from IRQ" mistake - that's definitely a bogus thing to do. But if the kernel is not running, then a failed mutex lock attempt is not really harmful. (Assuming they unlock before the kernel is started again).

[kjbracey]

Is singleton_mutex_id getting set before the kernel is started?

Yes, it is. Okay, then setting it at the start of mbed_start would be another approach. I think that seems reasonable - we don't run the general C++ setup until then, so doing it as the first thing before mbed_toolchain_init() seems like it will be fine.

We're already assuming single-threaded at least until that call is made - but that could spawn new threads in object constructors.

[ciarmcom]

@hugueskamba, thank you for your changes.
@korjaa @LMESTM @evedon @c1728p9 @kjbracey-arm @ARMmbed/mbed-os-core @ARMmbed/mbed-os-maintainers please review.

[hugueskamba]

Is singleton_mutex_id getting set before the kernel is started?

Yes, it is. Okay, then setting it at the start of mbed_start would be another approach. I think that seems reasonable - we don't run the general C++ setup until then, so doing it as the first thing before mbed_toolchain_init() seems like it will be fine.

We're already assuming single-threaded at least until that call is made - but that could spawn new threads in object constructors.

Thanks. Done.

Pull request has been modified.

[kjbracey]

This can be properly publicly declared in mbed_boot.h. mbed_rtx_rtos.c doesn't seem to have its own header, but it includes mbed_boot.h, and that's where mbed_rtos_start is declared.

(Although maybe everything else there is public. Stick a @internal or whatever Doxygen uses on it).

[hugueskamba]

Done.
Everything is already internal documentation.

Pull request has been modified.

[0xc0170]

CI started

[mbed-ci]

Test run: SUCCESS

Summary: 6 of 6 test jobs passed
Build number : 1
Build artifacts

[mergify]

This PR does not contain release version label after merging.