nRF9160: Modem trace external flash backend

This sample demonstrates how to add a modem trace backend that stores the trace data to external flash.

Requirements 

The sample supports the following development kit, version 0.14.0 or higher:

Hardware platforms	PCA	Board name	Build target
nRF9160 DK	PCA10090	nrf9160dk_nrf9160	`nrf9160dk_nrf9160_ns`

The control signal from the nRF52840 board controller MCU (P0.19) must be set to high to let the nRF9160 communicate with the external flash memory. To do this, enable the external_flash_pins_routing node in the devicetree and program the Hello World sample for the nrf9160dk_nrf52840 board.

To enable the external_flash_pins_routing node in devicetree, add the following code in the devicetree overlay in the Hello World application:

&external_flash_pins_routing {
        status = "okay";
};

See Board controller for more details.

When built for an _ns build target, 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 

You can use this sample to implement storing and reading of modem traces on an external flash device. The sample contains an implementation of a custom trace backend that writes modem traces on the external flash chip of the nRF9160 DK. In addition, it reads out the traces from the external flash and writes them out to UART1 on a button press.

You can use the sample for creating a trace backend for your own flash device. You can store a reduced set of modem traces using the CONFIG_NRF_MODEM_LIB_TRACE_LEVEL_CHOICE option. The sample starts storing modem traces when the backend is initialized by the Modem library integration layer library. However, you can also start storing the modem traces during runtime. Use the nrf_modem_lib_trace_level_set() function for enabling or disabling modem traces at runtime.

Write performance 

A modem trace backend must be able to handle the trace data as fast as they are produced to avoid dropping traces. It is recommended to handle the trace data at approximately 1 Mbps. The Macronix MX25R6435 Ultra Low Power Flash on the nRF9160DK is optimized for low power consumption rather than write speed, but it features a high performance mode. The high-performance mode consumes more power but is able to erase and write at roughly double the speed. Use the device tree property mxicy,mx25r-power-mode to configure MX25R6435 in either high-performance or low-power mode. In this sample, the MX25R6435 is configured in high-performance mode.

The use of CONFIG_SPI_NOR_IDLE_IN_DPD option to enable deep-power-down mode significantly reduces the stand-by power consumption. However, it adds overhead for each SPI instruction, which causes an approximately 20% reduction in write performance.

The sample uses the Modem library to turn on and off the modem traces and also enable and disable the modem. In addition, it uses the UART to send modem traces over UART1.

Flash space 

The sample uses 1 MB (out of 8 MB) of the external flash. This is sufficient for the modem traces that are handled by this sample. Since the external flash area is erased during startup, the size of the flash used affects the startup time. Erasing 1 MB takes approximately 8 seconds in high performance mode. Erasing the whole flash (8 MB) takes approximately 1 minute in high performance mode.

User interface 

Button 1:: Reads out the modem traces from external flash and sends it on UART 1.

Building and running 

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

When built as firmware image for the _ns build target, 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 with Visual Studio Code, follow the steps listed on the How to build an application page in the nRF Connect for VS Code extension documentation. See Building and programming an application for other building and programming scenarios and Testing and debugging an application for general information about testing and debugging in the nRF Connect SDK.

Testing 

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

After programming the sample and board controller firmware (as mentioned in Requirements section) to your development kit, test it by performing the following steps:

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.
Connect to the kit with a terminal emulator (for example, PuTTY). See How to connect with PuTTY for the required settings.
Open the Trace Collector desktop application and connect it the DK.
When the console output Flushed modem traces to flash is received, press Button 1 on the development kit.
Observe modem traces received on the Trace Collector desktop application.

Note

Since the external flash is erased at startup, there will be a few seconds of delay before the first console output is received from the sample.

Dependencies 

It uses the following sdk-nrfxlib libraries:

Modem library

It uses the following Zephyr libraries:

UART

In addition, it uses the following secure firmware components:

Trusted Firmware-M