Update to sdk 8.1

[LiyouZhou]

1. Bring the base of evey file in nordic_sdk up to nrf51-sdk 8.1.0.
2. Reapply relevant changes we made.

@rgrover @andresag01 Please review.

[rgrover]

thakns for this pull request. I'll review this shortly.

[rgrover]

all this looks good to me. Since we've incorporated some changes to pstorage, it would be nice if we could re-test with the URI_Beacon (or any other demo which tries to use persistent storage). I'll defer to @andresag01 for his OK. Let's try to avoid changes which add warning messages. Thanks @LiyouZhou

[rgrover]

could you also confirm that we don't need to update our softdevice hex files to match this new SDK? I believe we're already taking our softdevice from SDK8.1, but I could be wrong about that.

[andresag01]

@rgrover @LiyouZhou : The softdevice files we are using are these ones. I am not sure how the versioning works but the file names say:

• s130_nrf51_1.0.0_softdevice.hex
• s110_nrf51822_8.0.0_softdevice.hex

[rgrover]

@LiyouZhou please check if we could benefit from a different softdevice from SDKv8.1.

[rgrover]

@LiyouZhou could you please also review the release notes for v8.1 of the Nordic SDK to help clarify what benefits exist in upgrading to it? We will be upgrading the Nordic SDK over time, but we should try to document any major benefits at each upgrade step--if such benefits exist.

[andresag01]

@rgrover I have just tried the URIBeacon demo in ble-examples and it seems to behave as expected i.e. I am able to connect, configure something. Then when I reset the device my configuration is retained, I assume because it was saved in permanent storage.

[rgrover]

ok. I'm satisfied with our upgradability to v8.1 of the SDK. I'd just like confirmation about the softdevice hex file.

[LiyouZhou]

@rgrover I can confirm current headers are from s130_nrf51_1.0.0 softdevice. Softdevice have some definition changes, be I see no obvious performance benefit. I would like to keep the softdevice upgrade a separate effort as it needs more thought and investigation. S130v2 is at alpha release stage and may not be fully compatible with sdk 8.1.

[LiyouZhou]

@rgrover Here are some benefits from the sdk v8.1 release notes:

Highlights:

• Support for SoftDevice S130 v1.0.0
• Serialization supporting SoftDevice S110, S120, and S130
• ANCS updated and no longer in experimental state
• GCC updated to new version: ARMGCC 4.9 q1-2015
• DFU example now has support for IAR and GCC

Changes:

ANT + BLE (dual stack):

• Not included in this release due to conflicting interface between SoftDevice S310 and S110. Use SDK v7.2.0 for S310 support.
• S310 support will be reintroduced in a future release.

  BLE:

• SoftDevices:
  • Support for S130 v1.0.0.
• Serialization:
  • Fully serialized S110, S120, and S130 API.
• Modules/Services:
  • New button module (bsp_btn_ble) that enables functionality such as disconnect, turn off whitelist, go to sleep.
  • Advertising module now supports scan response data
• Examples:
  • ANCS example is no longer in experimental state.

    Proprietary:

  • IAR support for proprietary examples.

Fixed issues:

• NRFFOSDK-2044: Fixed issue in app_gpiote.
• NRFFOSDK-3855: Fixed issue in Current Time Service.

Known issues:

• Device Manager is not supported in multirole S130 operation.
  • Device Manager works in peripheral or central only operation on S130. This must be decided at compile time.
• The DFU over BLE example has been tested to work with a minimum connection interval of 11.25 ms. The application cannot handle connection intervals lower than 11.25 ms and may undergo a system reset in the middle of a firmware update. Workaround: If you face unexpected disconnects during the firmware update process, consider increasing the connection interval.
• ANT:
  • NRFFOSDK-755: HRM TX buttons example may report wrong total elapsed time.
• BLE:
  • A few APIs of the Device Manager are not implemented. Also, documentation providing examples of how the API can be used is missing.
  • NRFFOSDK-2824: Device Manager (pstorage) does not support update of bond split across two pages.
• Proprietary:
  • The nRF24Lxx ESB examples found in the legacy nRFready SDKs do not work out of the box with the nRF51 ESB examples. This is due to:
  • The legacy examples do not use "payload in ACK".
  • The legacy examples use RF channel 2 (not 10 as the nRF51 examples).
  • The examples do not use dynamic payload length. The legacy examples need to add the following to work with the nRF51 examples: hal_nrf_setup_dynamic_payload(0xFF); hal_nrf_enable_dynamic_payload(true); hal_nrf_enable_ack_payload(true); hal_nrf_set_rf_channel(10); In addition, the legacy PTX example must add code for handling the payloads received in ACK.
  • The Gazell Link Layer examples are not fully "out of the box" compatible with the legacy Gazell examples provided in the nRFgo SDK for nRF24Lxx devices. The timeslot periods and channel tables require adjustment.
  • Timeslot period: Edit the gzll_params.h file used in the nRF24Lxx projects or use the nrf_gzll_set_timeslot_period() function in the nRF51 projects (nRF51 Gazell timeslot period = 0.5*GZLL_RX_PERIOD).
  • Channel table: Edit the gzll_params.h file used in the nRF24Lxx projects or use the nrf_gzll_set_channel_table() function in the nRF51 projects.
  • Gazell does not support "Low Power Host mode" (Host mode 1).

[rgrover]

it all seems good to me. I'll go ahead with v8.1