mbed_die was calling wait_ms in a critical section - this is deprecated
behaviour, and caused a fatal error in debug builds, potentially leading
to an infinite reboot loop if this was caused due to a reboot limit
halt.
Switch to using wait_us - this is safe in a critical section. This does
trigger a call to mbed_warning, due to the large parameter, but that is
harmless - it doesn't output anything to the console, and won't
overwrite the error context if it already contains something.
Set tasklet parameters before connecting to prevent the parameters to be set to 0.
The tasklet parameters are reset to 0 when wisun_tasklet_connect gets called,
thus those need to be set in the wisun_tasklet_configure_and_connect_to_network
before they are used. This is also done this way in other tasklets.
The pre-main check of error_reboot_count was applied repeatedly on
every boot, meaning that once the reboot limit was hit, every subsequent
reset would halt before main, until something managed to clear
or corrupt the error context.
Set the is_error_processed flag before halting, so that when an external
agent resets us while we're halted, we do not report the error and halt
again.
A couple of places in mbed_retarget.cpp were testing for either ARMC5 or
ARMC6 in a long-winded fashion. Testing for __ARMCC_VERSION being
defined is sufficient.
Similar to SingletonPtr, use atomic accesses when loading the guard word
outside the lock, and when storing, to ensure no races for threads that
don't take the lock.
Lack of atomics unlikely to be a problem in current builds, but code
could conceivably be subject to reordering if link-time optimisation was
enabled.
SingletonPtr's implementation wasn't totally safe - see "C++ and the
Perils of Double-Checked Locking"by Meyers and Alexandrescu. No problems
observed in practice, but it was potentially susceptible to compiler
optimisation (or maybe even SMP issues).
Now that we have atomic loads and stores, the function can be made safe,
avoiding any potential races for threads that don't take the lock:
ensure that the unlocked load is atomic, and that the pointer store is
atomic.
See https://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/
for more discussion.
Like all HAL APIs, the calls in trng_api.h are not expected to
be thread-safe.
All current accesses to the TRNG HAL are currently via
`mbedtls_hardware_poll`. Mbed TLS does not currently serialise these
calls itself, as `MBEDTLS_THREADING_C` is not enabled. But even if
Mbed TLS's own accesses were serialised, there are other direct
users of `mbedtls_hardware_poll` such as randLIB, that need to use
direct calls due to lack of API to extract entropy from Mbed TLS.
As such it makes sense to treat `mbedtls_hardware_poll` as a de facto
public Mbed OS API, akin to the C++ veneers on top of the HAL, and add a
PlatformMutex there so that it is safe for multithreaded use.
Instead of doing a "pull --rebase" to update to the latest development
branch, do a "fetch" followed by a "checkout" to update to the specified
release. This enables us to get any new tags created since the last
update to the development branch, and removes the noise of updating a
local "development" branch.
As barriers were added in #9247, review comments pointed out that atomic
stores needed a second barrier, and they got one. But atomic_flag_clear
was missed.
paul-szczepanek-arm
Kevin Bracey
Jarno Lamsa
Martin Kojtal
Cruz Monrreal
Jimmy Brisson
Mahesh Mahadevan
Brian Daniels
Amir Cohen
Mirela Chirica
itayzafrir
Jaeden Amero
Ari Parkkila
Veijo Pesonen