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)

[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