What's the proper way to run nrf9160 DK's app working on nrf9160 SiP?

[Aleksei Vegner]

Hi there,

I'm having a lot of fun with running apps on nrf9160 SiP on board of nrf9160 DK.

nrf52840 SoC contains the standard board controller fw.

nrf9160 SiP contains the standard secure bootloader from samples and modem fw.

My app is very simple and uses only leds.

What I'm trying to do is just to blink by LED1 each 100 msec. Only Zephyr's main thread is being used.

The probability of a successful run when i see a blinking led is about 20-30% of all tries.

I've tried several DK start sequences and none of them give me a 100% success rate:

* switch DK off / on and wait

* switch DK off / on, push reset button (nrf91 debug state) and wait

* switch DK off / on, set nrf52 debug, push reset button and wait

* switch DK off / on, set nrf52 debug, push reset button, set nrf91 debug, push reset button and wait

3 sec delay has been added to the very beginning of the main thread to give time for the board controller to boot and init all routes.

In all successful runs it takes about 10-30 seconds to start blinking. 

What's the proper start sequence for nrf9160 DK?

[Martin Lesund]

Hi Alex,

Please share your code.

You should not need to add a delay in your main application, because it will not run parallel with the secure_boot. (it runs after)

If you are using the default board controller and only need to reset the nrf91 the Reset button should be enough.

Then again when you flash new firmware, it is recommended to power cycle the board. 

[Aleksei Vegner]

static void leds_init(void)
{
	int err;

	err = dk_leds_init();
	if (err) {
		printk("Could not initialize leds, err code: %d\n", err);
	}

	err = dk_set_leds_state(0, DK_ALL_LEDS_MSK);
	if (err) {
		printk("Could not set leds state, err code: %d\n", err);
	}
}

void main(void)
{
	static bool led_1_on = false;
	int err;
	u32_t leds_on_mask;

	printk("BLE to NB-IoT gateway started\n");
	leds_init();

	while (true) {
		led_1_on = !led_1_on;
		leds_on_mask = 0;
		if (led_1_on) {
			leds_on_mask |= DK_LED1_MSK;
		}

		err = dk_set_leds_state(leds_on_mask, DK_ALL_LEDS_MSK);
		if (err) {
			printk("Could not set leds state, err code: %d\n", err);
		}

		k_sleep(K_MSEC(200));
	}
}

# General config
CONFIG_NEWLIB_LIBC=y
CONFIG_TEST_RANDOM_GENERATOR=y
CONFIG_ASSERT=y
CONFIG_REBOOT=y

# Trusted execution
CONFIG_TRUSTED_EXECUTION_NONSECURE=y

# Network
CONFIG_NETWORKING=y
CONFIG_NET_SOCKETS=y
CONFIG_NET_SOCKETS_OFFLOAD=y

# MQTT
CONFIG_MQTT_SOCKET_LIB=y
CONFIG_MQTT_LIB_TLS=y
CONFIG_MQTT_MAX_PACKET_LENGTH=2048

# LTE link control
CONFIG_LTE_LINK_CONTROL=y

# BSD library
CONFIG_BSD_LIBRARY=y

# Disable Modem traces, since we need UART1 for HCI
CONFIG_BSD_LIBRARY_TRACE_ENABLED=n

# nRF Cloud
CONFIG_NRF_CLOUD=n

# Library for buttons and LEDs
CONFIG_DK_LIBRARY=y
CONFIG_DK_LIBRARY_INVERT_LEDS=n

# Console
CONFIG_CONSOLE_SUBSYS=y
CONFIG_CONSOLE_HANDLER=y
CONFIG_CONSOLE_GETCHAR=y

CONFIG_CONSOLE=y
CONFIG_STDOUT_CONSOLE=y
CONFIG_UART_CONSOLE=y

# Main thread
CONFIG_MAIN_THREAD_PRIORITY=7

# Enable Bluetooth stack and libraries
CONFIG_BT=y
CONFIG_BT_H4=y
CONFIG_BT_CENTRAL=y
CONFIG_BT_GATT_CLIENT=y
CONFIG_BT_GATT_DM=y
CONFIG_BT_SCAN=y
CONFIG_BT_SCAN_FILTER_ENABLE=y
CONFIG_BT_SCAN_UUID_CNT=1
CONFIG_BT_SCAN_ADDRESS_CNT=1

CONFIG_UART_2_NRF_UARTE=y
CONFIG_UART_2_NRF_FLOW_CONTROL=y
CONFIG_UART_INTERRUPT_DRIVEN=y

CONFIG_LOG=y
CONFIG_BT_GATT_DM_LOG_LEVEL_INF=y

# Heap and stacks
CONFIG_HEAP_MEM_POOL_SIZE=16384
CONFIG_MAIN_STACK_SIZE=8192

based on ncs/nrf/samples/nrf9160/lte_ble_gateway

<login@host>: cat ~/.zephyrrc 
export ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb
export GNUARMEMB_TOOLCHAIN_PATH="/opt/gnuarmemb"

<login@host>: . ~/nrf91/sdk/ncs/zephyr/zephyr-env.sh
<login@host>: cd ~/nrf91/sdk/ncs/nrf/samples/nrf9160/lte_ble_gateway
<login@host>: BOARD=nrf9160_pca10090 cmake -Bbuild -H.
<login@host>: cd build && make -j $(nproc)
<login@host>: nrfjprog --program zephyr/zephyr.hex -f nrf91 --sectorerase -r --verify
<login@host>: /opt/gnuarmemb/bin/arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.1 20181213 (release) [gcc-8-branch revision 267074]

[Aleksei Vegner]

Power cycling and/or reset after flashing don't help to get a 100% successful run. You're right SiP's app runs after secure boot.

I meant the following:

- DK has 2 onboard ICs (nrf52 + nrf91)

- when I switch DK on LED1 starts blinking for a very short moment of time

- it seems like board controller nrf52 interrupts (resets) SiP during power up, performs board initialization. That's why blinking stops

- then only after ~30-60 seconds led starts blinking again. But it's not guaranteed and resembles very random behaviour

I just can't figure out why each power up results in different time to run my SiP's app if it's been run at all.

[Martin Lesund]

Hi Alex,

First things first, the lte_ble_gateway sample is not necessary the best sample to build upon in your case where you test out basic functionality.

(for simple samples I would suggest you to check out this repository.)

---

The reason you see this "strange" behaviour is that you have enabled alot of things in the prj.conf file which you do not need.

For example, when you set:

# LTE link control
CONFIG_LTE_LINK_CONTROL=y

You say to the application to try to establish a link with a base station before your main runs. This can take ~30-60 seconds, and that is why you see this delay when running your application before the LED starts to toggle.

---

• What you can do is strip everything down from the lte_ble_gateway sample.

1. Only enable the necessary things in prj.conf

# Trusted execution
CONFIG_TRUSTED_EXECUTION_NONSECURE=y

# Library for buttons and LEDs
CONFIG_DK_LIBRARY=y
CONFIG_DK_LIBRARY_INVERT_LEDS=n 

2. Strip down the main.c

 

/*

* Copyright (c) 2012-2014 Wind River Systems, Inc.

*

* SPDX-License-Identifier: Apache-2.0

*/

#include <zephyr.h>
#include <misc/printk.h>
#include <dk_buttons_and_leds.h>

static void leds_init(void)
{
	int err;

	err = dk_leds_init();
	if (err) {
		printk("Could not initialize leds, err code: %d\n", err);
	}

	err = dk_set_leds_state(0, DK_ALL_LEDS_MSK);
	if (err) {
		printk("Could not set leds state, err code: %d\n", err);
	}
}

void main(void)
{
	static bool led_1_on = false;
	int err;
	u32_t leds_on_mask;

	printk("BLE to NB-IoT gateway started\n");
	leds_init();

	while (true) {
		led_1_on = !led_1_on;
		leds_on_mask = 0;
		if (led_1_on) {
			leds_on_mask |= DK_LED1_MSK;
		}

		err = dk_set_leds_state(leds_on_mask, DK_ALL_LEDS_MSK);
		if (err) {
			printk("Could not set leds state, err code: %d\n", err);
		}

		k_sleep(K_MSEC(200));
	}
}

3. Strip down the CMakeLists.txt

#
# Copyright (c) 2018 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-BSD-5-Clause-Nordic
#

cmake_minimum_required(VERSION 3.8.2)

include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake NO_POLICY_SCOPE)
project(NONE)

target_sources(app PRIVATE src/main.c)

---

• Or another option is to unzip  simple_led.zip in [ nrf\samples\nrf9160\] and build/run.

It should work out-of-the box with your specification for the application. (and it should be easier to build upon)

Best Regards,

Martin L.

[Aleksei Vegner]

Thanks a lot! Yes, the only option which is preventing a quick start is 

CONFIG_LTE_LINK_CONTROL=y

Disabling the option has helped.