• State Verified Answer
  • Replies 15 replies
  • Subscribers 88 subscribers
  • Views 3161 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 263035
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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)

Parents
  • 0

    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

  • 0 in reply to Carl Richard

    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.

  • 0 in reply to 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

  • 0 in reply to Carl Richard

    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

  • 0 in reply to Bard

    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

  • 0 in reply to 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

  • 0 in reply to Carl Richard

    Hi

    The changes to prj.conf didn't make any difference.

    After reloading the Blinky Project doing 'Clean Build Directory' (SEGGER embed studio), the secure version is ok, but not the nonsecure. Same behaviour running west from CLI. Trying to debug, the program never enters the nonsecure main.

    Bård

Reply Children
Related