Blinky not working on custom nrf5340 board

[Bard]

Hi

Migrating from NCS1.3.1 to NCS1.4.1, the Blinky sample stops working on my custom nrf5340 board. No compile error, but not running. I also have a nRF5340PDK. Works fine on this! Note that Blinky also works fine on my custom board when using NCS1.3.1.

How can I debug this?

Since Blinky works fine with NCS1.3.1 and not with NCS1.4.1  it's no HW fail !?

But since Blinky works fine with both versions on the PDK, there's no SW fail !? 

note: initially I had this trouble: Case ID: 256874 https://devzone.nordicsemi.com/f/nordic-q-a/66280/blinky-non-secure-sample-not-running (maybe they are the same)

[Carl Richard]

Hi!

Which revision of the nRF5340 chip are you using for your HW? I'm asking this as we released revision 1 in december, which behaves a bit differently compared to the engineering samples. Anyway, if you have the oppertunity to step through the code in SES we could get some idea of what's actually happening. 

Are you using a custom board file (.DTS) for your board? 

As for the other issue I will talk with Håkon and see what his thoughts are. I guess it can be related to how the pin is configured in the code.

Best regards,
Carl Richard

[Bard]

I'm using the engineering version marked nRF5340 QKAAAE 1940AB. The DK has nRF5340 QKAAAE 1934AB

I'm able to step thru code on both targets (PDK and Custom). The code on custom board never enters main loop. I can step to line 479 in init.c: switch_to_main_thread(prepare_multithreading()); But stepping further; the code loop thru fault_s.S (enters line80) and bak to line 479 in init.c.

Using NCS 1.3.1 both targets are debugged ok. Starting in main(void) in main.c <- NO SPM

Note: Trying to enable SPM in NCS 1.3.1, I get the following compile error:

c:/nordicsdk/v1.3.1/toolchain/opt/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: modules/nrf/subsys/fw_info/lib..__nrf__subsys__fw_info.a(fw_info.c.obj):(.firmware_info+0xc): undefined reference to `_fw_info_size'

I'm using the same DTS for both boards -> identical code.

[Carl Richard]

Is this the case for both your modified Blinky sample (from the other ticket) and the original Blinky sample? If possible, could you give me a screenshot of SES from then the sample has entered the fault state. I want to take a look at the call stack and registers.

How are other applications performing? Could you maybe try the Zephyr hello_world sample?

Best regards,
Carl Richard

[Bard]

I have modified my Blinky back to (nearly) the original Blinky. -> same issue.

hello_world is ok on PDK and debugger is running. On Custom board same issue as Blinky.

main.c : (nearly same as original Blinky)

/*
 * Copyright (c) 2016 Intel Corporation
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include <zephyr.h>
#include <device.h>
#include <devicetree.h>
#include <drivers/gpio.h>

/* 1000 msec = 1 sec */
#define SLEEP_TIME_MS   1500

/* The devicetree node identifier for the "led0" alias. */
#define LED0_NODE DT_ALIAS(led0)
#define LED1_NODE DT_ALIAS(led1)

#if DT_NODE_HAS_STATUS(LED0_NODE, okay)
#define LED0	DT_GPIO_LABEL(LED0_NODE, gpios)
#define PIN	DT_GPIO_PIN(LED0_NODE, gpios)
#define FLAGS	DT_GPIO_FLAGS(LED0_NODE, gpios)
#else
/* A build error here means your board isn't set up to blink an LED. */
#error "Unsupported board: led0 devicetree alias is not defined"
#define LED0	""
#define PIN	0
#define FLAGS	0
#endif

#if DT_NODE_HAS_STATUS(LED1_NODE, okay)
#define LED1	DT_GPIO_LABEL(LED1_NODE, gpios)
#define PIN1	DT_GPIO_PIN(LED1_NODE, gpios)
#define FLAGS1	DT_GPIO_FLAGS(LED1_NODE, gpios)
#endif

void main(void)
{
	const struct device *dev;
	const struct device *dev1;
	//const struct device *pin_dev;
	bool led_is_on = true;
	int ret;

	dev = device_get_binding(LED0);
	if (dev == NULL) {
		return;
	}
	dev1 = device_get_binding(LED1);
	if (dev1 == NULL) {
		return;
	}

	ret = gpio_pin_configure(dev, PIN, GPIO_OUTPUT_ACTIVE | FLAGS);
	if (ret < 0) {
		return;
	}
	ret = gpio_pin_configure(dev1, PIN1, GPIO_OUTPUT_ACTIVE | FLAGS1);
	if (ret < 0) {
		return;
	}

   	//pin_dev = device_get_binding("GPIO_0");
    //    gpio_pin_configure(pin_dev, 24, GPIO_OUTPUT);
    //    gpio_pin_configure(pin_dev, 16, GPIO_OUTPUT);

	while (1) {
		gpio_pin_set(dev, PIN, (int)led_is_on);
		gpio_pin_set(dev, PIN1, (int)led_is_on);
		//gpio_pin_set(pin_dev, 24, (int)led_is_on);
		//gpio_pin_set(pin_dev, 16, (int)led_is_on);
		led_is_on = !led_is_on;
		k_msleep(SLEEP_TIME_MS);
	}
}

[Carl Richard]

Thanks. I will look into it.

Could you add the following #else to the DT_NODE_HAS_STATUS(LED1_NODE, okay) check aswell and see if the build returns an error?

 

/* A build error here means your board isn't set up to blink an LED. */
#error "Unsupported board: led1 devicetree alias is not defined"
#define LED0	""
#define PIN	0
#define FLAGS	0
#endif

Just want to make sure that the LED is actually found.

Best regards,
Carl Richard

[Bard]

just added it -> no compile error. Both LEDS are blinking on the PDK.

[Carl Richard]

Ok. Now that I think of it that makes sense as you're using the same DTS-file. I believe your error may be related to changes in the DTS file between the NCS versions. Looking into that now.

Best regards,
Carl Richard

[Carl Richard]

Hi again!

Apologies for the slow progress of this issue. I have not managed to reproduce it here and I'm awaiting answers from the developers on possible issues. Please try out the attached .hex-files on your devices, so that we can rule out any environment issues. One is compiled for the PDK and the other for the DK.

DK: 5126.blinky_dk.hex

PDK: 2063.blinky_pdk.hex

In addition, could you try to step through again and copy the full register values here when it crashes? Press the button as shown in the picture below:

Best regards,
Carl Richard

[Bard]

Hi

I first read the registers (see below). Then I tested the two images first on the PDK and then on the custom board. The pdk variant functioned well on the PDK (led blinking). No led blink with dk version. On Custom Board neither blinked.

Sadly, after doing these exercises, the JLink interface is broken! Cannot connect to target anymore. Any tips?

EDIT: Reboot fixed the latter issue. JLink working again.

Registers when it crashes:

CPU - Current Context
r0 0x00009244
r1 0x00009244
r2 0x00009244
r3 0x00009244
r4 0x00009244
r5 0x00009244
r6 0x00009244
r7 0x00009244
r8 0x00009244
r9 0x00009244
r10 0x00009244
r11 0x00009244
r12 0x00009244
sp(r13) 0x200015b8
lr(r14) 0xffffffbd
pc(r15) 0x000017e4
apsr 0x01000007
V 0
C 0
Z 0
N 0
CPU
r0 0x00009244
r1 0x00009244
r2 0x00009244
r3 0x00009244
r4 0x00009244
r5 0x00009244
r6 0x00009244
r7 0x00009244
r8 0x00009244
r9 0x00009244
r10 0x00009244
r11 0x00009244
r12 0x00009244
sp(r13) 0x200015b8
lr(r14) 0xffffffbd
pc(r15) 0x000017e4
xpsr 0x01000007
ISR 7
IT[7:2] 0x00
GE 0x0
T 1
IT[1:0] 0x0
Q 0
V 0
C 0
Z 0
N 0
msp 0x200015b8
psp 0x20000b98
cfbp 0x00000000
PRIMASK 0
BASEPRI 0x00
FAULTMASK 0
nPRIV 0
SPSEL 0
FPCA 0
SFPA 0
msp_ns 0x200086a0
psp_ns 0x00000000
msp_s 0x200015b8
psp_s 0x20000b98
msplim_s 0x20000db8
psplim_s 0x20000878
msplim_ns 0x00000000
psplim_ns 0x00000000
cfbp_s 0x00000000
PRIMASK 0
BASEPRI 0x00
FAULTMASK 0
nPRIV 0
SPSEL 0
FPCA 0
SFPA 0
cfbp_ns 0x00000000
PRIMASK 0
BASEPRI 0x00
FAULTMASK 0
nPRIV 0
SPSEL 0
FPCA 0
SFPA 0
internal 0x00000001
mode 1
state 0

[Carl Richard]

Thanks for the registers. The JLink-interface should be restored if you call "nrfjprog --recover" on the command line. Please report back if that does not work!

We can now rule out that this is an environment issue at least. 

Best regards,
Carl Richard

[Carl Richard]

Hi again!

I'm awaiting input from the developers on this now. In the meantime I wondered if you have gotten the custom board reviewed earlier? While I find it hard to believe the hardware to be an issue given that it worked for v1.3.1 it may be beneficial to have someone look over the design.

In addition I want you to try to set the following configurations in the Blinky prj.conf:

CONFIG_NRF5340_CPUAPP_ERRATUM19=n
CONFIG_HW_STACK_PROTECTION=n

Report back to me if that affects the behavior or not. Thanks!

Best regards,
Carl Richard