Only release if the current _connect_status is CONNECTING. If the semaphore is released many times for each connect, then the next connect will not wait(), as it will be able to decrement the semaphore imediatelly.
At the start-up, there was 2 NSAPI_STATUS_CONNECTING callbacks,
so extra one removed from ThreadInterface.cpp.
At the network lost case, there was NSAPI_STATUS_DISCONNECTED and
NSAPI_STATUS_LOCAL_UP callbacks. NSAPI_STATUS_DISCONNECTED has been removed,
since the NSAPI_STATUS_LOCAL_UP is enought.
Nanostack v10.1.0 for Mbed OS 5.12
* commit '780e9afb8f3b8f09e66573e7d4ba096dd9a87dd7':
Squashed 'features/nanostack/sal-stack-nanostack/' changes from 513a38e..c5ee9e4
There are two EventQueue.h in mbed-os codebase:
events/EventQueue.h
features/FEATURE_BLE/ble/pal/EventQueue.h
By accident, `mbed compile` generates includes.txt with the correct
order of include search paths. This is not the case for the CMake
exporter: targets with FEATURE_BLE enables fail to compile with errors:
mbed-os/features/cellular/framework/AT/ATHandler.h:99:60: error:
'events' has not been declared
Update all places to always include either "events/EventQueue.h"
or "ble/pal/EventQueue.h": to always find the correct header.
Fix the following build warning seen with GCC
Compile [ 51.2%]: thread_bootstrap.c
[Warning] thread_extension.h@88,44: statement with no effect [-Wunused-value]
Fix the following build warning seen when building with GCC
Compile [ 54.2%]: icmpv6.c
[Warning] icmpv6.c@1091,16: this statement may fall through [-Wimplicit-fallthrough=]
Socket network interface tests were failing due to DICONNECTED event
being advertised, where GLOBAL_UP was expected. It turned out that
nanostack receives two events: APPL_EVENT_CONNECT and
APPL_BACKHAUL_INTERFACE_PHY_UP. The second attempt to connect obviously
returns errors, but it also causes events to be sent out to the
application. The second attempt should not take place in case the
bootstrap is already started.
I also fixed two reports being sent with DISCONNECT status, while they
are actually something else.
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.
Fix the following build warning found when building with
ARMC6 toolchain for NRF52_DK with mbed cli version 1.8.3
[Warning] thread_mle_message_handler.c@762,0: #188-D: enumerated type mixed with another type
[Warning] thread_mle_message_handler.c@834,0: #188-D: enumerated type mixed with another type