band_t structure in phy parameters was not being filled in properly
and we were spilling over the array boundary for bands.
In addition to that two utility functions are added to perform safety
checking taking in the frequency and filling out band information plus
boundry value checks.
In order to have smaller and better testable methods, instead of having a big
switch-case -style add_mac_command(), each MAC command is now separated to an
own method.
* Updates driver library to v2.3.1 (2018q1) for bugfixes and convenience functions
* Provides library in correct format (2-byte wchar_t flag) for compiling with ARMCC (#6695 uncovered by #6577)
* Reverts to using a statically-allocated packet buffer since malloc is not thread-safe (and the asserts have been turned on)
* Add NRF_SD_BLE_API_VERSION=5 macro to MCU_NRF52832 target
* Added initial Softdevice v5 API support for nRF5XPalGattClient.cpp
* Added initial Softdevice v5 API support for nRF5xGap.h
* Added initial Softdevice v5 API support for nRF5xGattServer.cpp
* Make sure the ah() hash function used by the security manager is declared with C linkage
* Removed 'ARM porting pending' checks in Nordic SDK
* Added BLE configuration to mbed_lib.json for NRF52x targets
* Migrated APIs and events model for Nordic SDK14.2 & SD API v5 in btle.cpp; adopted polling dispatch model
* Migrated APIs and events model for Nordic SDK14.2 & SD API v5 in nRF5xn.cpp
* Migrated APIs and events model for Nordic SDK14.2 & SD API v5 in nRF5xGap.cpp
* Added const qualifier to hwCallbacks's p_ble_evt parameter in nRF5xGattServer
* Add workaround to enable Radio Notification module from Nordic SDK
* Disabled SWI1 interrupt manually from SWI driver module
* Added missing include directive for "nrf_nvic.h" in ble_radio_notification.c
* Set correct number of custom UUIDs
* Adjust Softdevice RAM requirements for NRF52832/S132
* RAM settings for the application were adjusted as follow:
* Start: 0x20003800
* Size: 0xC800
* Adjust Softdevice RAM requirements for NRF52840/S140
* RAM settings for the application were adjusted as follow:
* Start: 0x20003700 (was 0x20003000)
* Size: 0xC900
* Added 3dBm as a permitted TX Power value for NRF52832
* Fix address type recovery in GAP
* Return min non-connectable adv interval compatible with infrastrcture's expectations
* Moved BLE driver from TARGET_SDK_14_2/FEATURE_BLE to TARGET_SDK_14_2/TARGET_SOFTDEVICE_COMMON/ble
Currently lora stack will automatically send an empty uplink message to lora gateway in case of:
- Node received message with pending bit set.
- Node received MAC command which requires instant response (sticky MAC command)
- Node received confirmed message in class C mode
This commit makes this configurable via config item
"automatic-uplink-message": {
"help": "In case of pending bit, class c confirmed message or sticky MAC command, stack will automatically send empty uplink message",
"value": true
}
Default value is true. If sending an empty message fails, stack will send event AUTOMATIC_UPLINK_ERROR application.
If automatic uplink sending is disabled, stack will send application UPLINK_REQUIRED -event to indicate
application should issue a new uplink to gateway as soon as possible.