nRF52840 custom board won't boot without debugger "kick" start

[laurentc]

Hello, 

I have a problem that looks a bit like

devzone.nordicsemi.com/.../nrf52840-custom-board-won-t-boot-without-debugger-reset

For me, to be more precise:

nRF52840 custom board won't even reach mcuboot's main() without debugger "kick" start

but it will start on a DK PCA10056 (nRF rev3)

Context  :
tests done on
target with a 32Mhz quartz and no 32.768Khz quartz, uses P0.0 and P0.1 as a serial port.

tests also done on
DK_1 : Modified DK for tests of my FW (PCA10056)
Modifed to match as much as possible my target
Disconnected the 32.768Khz quartz,
My FW uses P0.0 and P0.1 as a serial port
Re routed P0.0 and P0.1 toward the USB CDC pass through so that I can debug by USB the serial messages

FW is Using mcumgr for bootloader

Compiled with nRFConnect SDK v2.1.0

cpu on target : NRF52840_xxAA_REV2 ( I am sure that this is my target and not the nRF of the DK_2, that DK_2 has a rev3 )

cpu in DK_1 : NRF52840_xxAA_REV3

On the DK_1, my firmware works like a charm.

DK_2 : Another DK, unmodified.

My setup for testing on the target, is to use P20 of DK_2 to connect to the SWD of my target. 
Reset pin of the nRF on the target is not connected to the DK_2. (GPIO from another CPU, that I can put also in HZ, but that does not help)

If I start a debug session on my target using P20 of DK_2, everything is fine :
flash of the target, breakpoint just before do_boot, run to continue.

Even after stopping the debugger and switching it off, the target continues ok. And, now the most strange : I can even reset my target, and it will restart OK.

However, if I switch off my target and switch it on, even if I reset (push button) it after, I will not properly start. 
I can tell that it does not even reach the main() of mcuboot. (I did put some  uart_poll_out() commands everywhere to check )    [yes, I have checked that uart_poll_out works when I can boot]

So, it seems that the nRF is locked in the very first phases. We even think that the 32Mhz clock is not running.

Same problem if I just flash the board and reset it. 

The other person that had a similar problem found that by triggering the watchdog in case of a power on reset that would solve his problem
My problem is that I don't even reach the mcuboot code... so I can do nothing.

Could that have something to do with an errata of Rev 2 ?

Is there anywhere, in the config a place to precise the revision of my CPU, so that the correct workarounds are compiled ?

I have already spend 2 weeks on that...

Laurent

[Sigurd]

Hi,

1) You are running the exact same FW on the custom board and the DK, and you are only having this issue on the custom board? Correct?

2) Are you using DCDC?

3) In nRF Connect SDK, what board target are you building for? Did you create your own board files for the custom board?

4) Do you see the same issue with samples that don't use mcuboot?

[laurentc]

Yes to both of your questions. To be even more precise, after having compiled and run the FW on the DK_1. I close nRFConnect. Switch off DK_1. Connect the target and flash it with the generated merged.hex through the DK_2.

This way, I am sure that it is exacly the same binary.

[laurentc]

I am OK to provide all the information needed in a private thread. with schematics, and full project.

4) Yes I do. I just tried with a radio_test without mcuboot. (still compiled in the same dev env)

See below only differences.

Again, I have tried. Exactly the same behavior. Will start only with the debugger and then can be reset by my CPU and will restart. 

I have been given some example hex, not compiled with nrfconnect that do start correctly on our target.

1) Yes.
2) No. We have no external LC filter.  DCC left not connected.  Note : Do not enable the DC/DC regulator without an external LC filter being connected as this will inhibit device operation, including debug access, until an LC filter is connected.

3) As I said, I modified the DK_1 in order to look quite like our design.

Practically, 

I target the nrf52840dk_nrf52840

For radio_test without mcuboot all changes are :

prj.conf modified with

# No 32.768Khz Quartz

CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n

AND with added overlay file

/ {

    buttons {

        compatible = "gpio-keys";

        button4: button_4 {

            gpios = <&gpio1 15 (GPIO_PULL_DOWN | GPIO_ACTIVE_HIGH)>;

            label = "Nordic_CONN";

        };

    };

    aliases {

        sw4 = &button4;

    };  

};

&pinctrl {

    uart0_default: uart0_default {

        group1 {

            psels = <NRF_PSEL(UART_TX, 0, 0)>;

        };

        group2 {

            psels = <NRF_PSEL(UART_RX, 0, 1)>;

            bias-pull-up;

        };

    };

    uart0_sleep: uart0_sleep {

        group1 {

            psels = <NRF_PSEL(UART_TX, 0, 0)>,

                <NRF_PSEL(UART_RX, 0, 1)>;

            low-power-enable;

            bias-pull-up;

        };

    };

};

&uart0 {

    status = "okay";

    current-speed = <115200>;

};

 

nota : same problem without the bias-pull-up in the  uart0_sleep  section

[laurentc]

Hum, I see that in the default dk conf, the DCDC is enabled...
I try 

CONFIG_BOARD_ENABLE_DCDC=n

...

and it works...

What a relief.

I would recommend that the default prj.conf has the line CONFIG_BOARD_ENABLE_DCDC=y

even if it is the default value.

[Sigurd]

laurentc said:

I try 

CONFIG_BOARD_ENABLE_DCDC=n

...

and it works...

What a relief.

Great to hear it's now working!