Custom board with nRF5340: after reset firmware does not run and SWD is locked

[denis]

I'm using ncs 3.2.1 with a custom board (Holyiot-20046-v1.0).  I used the "Create a new board" function in nRF Connect VSCODE to create the board file.  I copied the Zephyr Blinky sample and added an alias for led0.  All builds and run from the debugger.  However, if I power cycle the board the firmware does not run and SWD is locked.

What is the correct procedure to setup the build so that the firmware does run and SWD is not locked?

Also, how can I set a breakpoint before the firmware is run so that I can debug the startup sequence and see why SWD is not being unlocked?

Additional Info:

I have tried using sys build explicitly with the following in sysbuild.conf:

SB_CONFIG_NETCORE_EMPTY=y

That does build a net app and I can flash them both, but it still seems to have the same issue of firmware not running and SWD is locked.

[Hung Bui]

Hi Denis, 

Could you give more log when you try to flash the board after the initial programming ? How did you do programming  ? 
 Please be aware that by default after programming the APPROTECT will be activated locking the SWD interface. 
When you have APPROTECT locking SWD you still can recover the chip by using nrfjprog --recover 
Please double check to see if your module has the inductor for DCDC (L5 inductor on the Holyiot-20046 schematic) and the 32kHz crystal. 

Could you try to compile the blinky example for DK and try flashing on the module. At least you should be able to step in the code. There could be a chance that there is an issue with the custom board file you created. Have you copied the board files for the DK and adjust it to the module ? 

[denis]

Thanks for the tips.  I think the DCDC inductors must not be populated.  Adding the following to the dts resolved the issue:

&vregmain {

    regulator-initial-mode = <NRF5X_REG_MODE_LDO>;

};

Might be a good idea for the ncs "Create a new board" wizard to do that by default (or better yet have check box options to indicate if the DCDC and XLF components are present).

[denis]

I have added the following to *cpuapp.dts:

&vregmain {

regulator-initial-mode = <NRF5X_REG_MODE_LDO>;

};

&vregradio {

regulator-initial-mode = <NRF5X_REG_MODE_LDO>;

};

And the following to prj.conf:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

I do not need to erase and recover any more however, so some progress.

However, still having some issues.  After the first power cycle of the board, I can attach the debugger and the code is running.  However, after another power cycle I can attach the debugger, but the code does not seem to be running.  The debugger just shows:

0xeffffffe in ?? ()

rather than:

arch_cpu_idle () at /Users/denis/sandbox/denisbohm/gremlins-playground/workspace/zephyr/arch/arm/core/cortex_m/cpu_idle.c:99

99 SLEEP_IF_ALLOWED(__WFI);

[New Thread 536872192]

[New Thread 536872000]

[New Thread 536872672]

Thread 3 received signal SIGTRAP, Trace/breakpoint trap.

[Switching to Thread 536872000]

arch_cpu_idle () at /Users/denis/sandbox/denisbohm/gremlins-playground/workspace/zephyr/arch/arm/core/cortex_m/cpu_idle.c:99

99 SLEEP_IF_ALLOWED(__WFI);

When in the non-working state, the debugger pause function doesn't work so I can't examine registers, memory, etc.

Any idea why it would work after one power cycle, but not the second?

Does the net core need to be built and programmed with any special options?  Does "nrfjproj --recover --coprocessor CP_NETWORK" flash the network core with empty firmware?

[Hung Bui]

Hi Denis, 
nrfjproj --recover --coprocessor CP_NETWORK does write to the network core with a small image that disable APPROTECT. 

Regarding the issue with debugger and power reset, did the application run normally when you do a second power reset ? And the issue was only with the debugger ? In your code do you do anything special ? Have you tested with a very simple code of blinking an LED? 

[denis]

The firmware does not run properly after a power cycle.

I'm using the Zephyr Blinky sample for testing.  When I flash and debug from VSCode it works fine.  When I power cycle the board, the firmware does not appear to run - the LED does not flash.  However, I can connect the debugger and then the firmware does run.  If I power cycle a few more times, then I cannot even attach the debugger.  When I flash and debug from VSCode again, it starts working again.

[Hung Bui]

Hi Dennis, 
From what showed in the schematic of the module, there is an inductor on DCCH pin. So it's quite strange that setting regulator-initial-mode to LDO changed the behavior. 

Do you have a 2nd board that you can test with ? Just in case it's an issue with one single board. 

If you have a nRF5340 DK , can you compile an application for the custom board and flash on the DK, do you see the same problem ? I think this should reveal if it's the issue with the hardware on the board or it's the firmware configuration. 

If you don't have a DK, have you tried to flash an application built for a DK to the custom board ? From what I can see you should be a able to run a default application for the DK on the module as it  has both the crystals, and DCDC enabled.