Download client

The Download client sample demonstrates how to download a file from an HTTP or a CoAP server, with optional TLS or DTLS. It uses the Download client library.

Cellular connectivity is supported on the nRF91 Series SiPs, while Wi-Fi® connectivity is supported on the nRF52 or nRF53 Series SoCs hosting the nRF70 Series Wi-Fi companion ICs.

The sample uses the connection manager that provides a common connectivity API for LTE and Wi-Fi stacks.

Requirements

The sample supports the following development kits:

Hardware platforms

PCA

Board name

Board target

nRF9161 DK

PCA10153

nrf9161dk

nrf9161dk/nrf9161/ns

nRF9160 DK

PCA10090

nrf9160dk

nrf9160dk/nrf9160/ns

nRF9151 DK

PCA10171

nrf9151dk

nrf9151dk/nrf9151/ns

nRF7002 DK

PCA10143

nrf7002dk

nrf7002dk/nrf5340/cpuapp/ns

Native Simulator

native_sim

native_sim

When built for a board target with the */ns variant, the sample is configured to compile and run as a non-secure application with Cortex-M Security Extensions enabled. Therefore, it automatically includes Trusted Firmware-M that prepares the required peripherals and secure services to be available for the application.

Overview

The sample first initializes the Modem library and AT communications. Next, it provisions a certificate to the modem using the Modem key management library if the CONFIG_SAMPLE_SECURE_SOCKET option is set. When using an nRF91 Series device, the provisioning of the certificates must be done before connecting to the LTE network since the certificates can only be provisioned when the device is not connected. The certificate file name and security tag can be configured using the CONFIG_SAMPLE_SEC_TAG and the CONFIG_SAMPLE_CERT_FILE options, respectively.

The sample then performs the following actions:

  1. Establishes a connection to the network

  2. Optionally sets up the secure socket options

  3. Uses the Download client library to download a file from an HTTP server.

Downloading from a CoAP server

To enable CoAP block-wise transfer, it is necessary to enable Zephyr’s CoAP stack using the CONFIG_COAP option.

Using TLS and DTLS

By default, the CONFIG_SAMPLE_SECURE_SOCKET option is set, which means that the sample provisions the certificate found in the samples/net/download/cert folder. The certificate file name is indicated by the CONFIG_SAMPLE_CERT_FILE option. This certificate will work for the default test files. If you are using a custom download test file, you must provision the correct certificate for the servers from which the certificates will be downloaded.

The certificate is automatically converted to a HEX format in the CMakeLists.txt file. The generated .inc file is then included in the code, where it is provisioned to the modem.

See Certificates for more information.

Configuration

See Configuring and building an application for information about how to permanently or temporarily change the configuration.

Configuration options

Check and configure the following configuration options for the sample:

CONFIG_SAMPLE_SECURE_SOCKET - Secure socket configuration

If enabled, this option provisions the certificate to the modem.

CONFIG_SAMPLE_SEC_TAG - Security tag configuration

This option configures the security tag.

CONFIG_SAMPLE_CERT_FILE - Certificate file name configuration

This option sets the certificate file name.

CONFIG_SAMPLE_COMPUTE_HASH - Hash compute configuration

If enabled, this option computes the SHA256 hash of the downloaded file.

CONFIG_SAMPLE_COMPARE_HASH - Hash compare configuration

If enabled, this option compares the hash against the SHA256 hash set by CONFIG_SAMPLE_SHA256_HASH for a match.

CONFIG_SAMPLE_SHA256_HASH - Hash configuration

This option sets the SHA256 hash to be compared with CONFIG_SAMPLE_COMPUTE_HASH.

Configuring Wi-Fi access point credentials

This sample uses the Wi-Fi credentials library to manage Wi-Fi credentials. Before the sample can connect to a Wi-Fi network, you must configure at least one credential set.

Once you have flashed your device with this sample, connect to your device’s UART interface and add credentials using the following command:

wifi_cred add NetworkSSID SecurityMode (OPEN, WPA2-PSK, WPA2-PSK-SHA256, WPA3-SAE) NetworkPassword

Where NetworkSSID is replaced with the SSID of the Wi-Fi access point you want your device to connect to, and NetworkPassword is its password. If you are not sure which security mode to use, enable the CONFIG_NET_L2_WIFI_SHELL Kconfig option and use the wifi scan command to display a list of all accessible networks along with their corresponding security modes. Then either reboot the device or use the wifi_cred auto_connect command to manually trigger a connection attempt.

From now on, these credentials will be automatically used when the configured network is reachable.

When building as firmware image for a non-secure board target, the Wi-Fi credentials backend will be set to PSA using TF-M.

See the Wi-Fi: Shell sample document for more details on the wifi_cred command.

Wi-Fi static credential options

If you want to configure the credentials statically, set the CONFIG_WIFI_CREDENTIALS_STATIC Kconfig option to y.

Important

Do not use static credentials in production environments.

Other options for statically configuring your Wi-Fi credentials:

Sending traces over UART on an nRF91 Series DK

To send modem traces over UART on an nRF91 Series DK, configuration must be added for the UART device in the devicetree and Kconfig. This is done by adding the modem trace UART snippet when building and programming.

Use the Cellular Monitor app for capturing and analyzing modem traces.

TF-M logging must use the same UART as the application. For more details, see shared TF-M logging.

Building and running

This sample can be found under samples/net/download in the nRF Connect SDK folder structure.

When built as firmware image for a board target with the */ns variant, the sample has Cortex-M Security Extensions (CMSE) enabled and separates the firmware between Non-Secure Processing Environment (NSPE) and Secure Processing Environment (SPE). Because of this, it automatically includes the Trusted Firmware-M (TF-M). To read more about CMSE, see Processing environments.

To build the sample, follow the instructions in Configuring and building an application for your preferred building environment. See also Programming an application for programming steps and Testing and optimization for general information about testing and debugging in the nRF Connect SDK.

Note

In the nRF repositories, building with sysbuild is enabled by default.

Testing

After programming the sample to your development kit, test it by performing the following steps:

  1. Connect the kit to the computer using a USB cable. The kit is assigned a COM port (Windows) or ttyACM device (Linux), which is visible in the Device Manager.

  2. Power on or reset the kit.

  3. Open a serial port connection to the kit using a terminal emulator that supports VT100/ANSI escape characters (for example, nRF Connect Serial Terminal). See Testing and optimization for the required settings and steps.

  4. Observe that the sample starts, provisions certificates, and starts to download.

  5. Observe that the progress bar fills up as the download progresses.

  6. Observe that the sample displays the message “Download completed” on the terminal when the download completes.

Sample output

The following output is logged on the terminal when the sample downloads a file from an HTTPS server:

Download client sample started
Provisioning certificate
Connecting to network
IP Up
Network connected
Downloading https://nrfconnectsdk.s3.eu-central-1.amazonaws.com/sample-img-100kb.png
[ 100% ] |==================================================| (102923/102923 bytes)
Download completed in 13679 ms @ 7524 bytes per sec, total 102923 bytes
IP down
Disconnected from network
Socket closed
Bye

Dependencies

This sample uses the following nRF Connect SDK libraries when using an nRF91 Series device:

It uses the following sdk-nrfxlib library:

In addition, it uses the following secure firmware component: