Interesting Issue with board configuration - application wont start unless "kickstarted" by RTT or debugger.

[schumac]

nRF Connect SDK version 2.2.0

I have a custom board with a Fanstel BC840 pre-certified module. The components for the low-voltage DCDC converter are included in that package - and I have included the components to enable the high voltage DCDC regulator, and enabled both of them in the board configuration. 

I do not have a 32kHz external crystal - and instead have enabled the 32kHz source to be the RC oscillator with:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

After flashing the board - absolutely nothing expected happens (bluetooth advertising, UICR to 3.3v, ect). Cycling the supply does nothing either, neither does debugger probe reset.

The second I either start a debugging session, or connect via RTT - the board suddenly comes to life and works as expected, I can even fully disconnect the debugger from the board and everything works as it should.

If I power cycle or reset the board, it stops working again until RTT is connected.

Things I think i've ruled out:

- Issue with power supply - if this were the case, I doubt the board would work after I disconnected the debugger entirely.
- Issue with HFC in the module - for the same reason as above, bluetooth works great as long as its "kickstarted" by the debugger. 

custom_board_definition.zip0435.prj.conf

[jrhaws]

We have very similar issues with our design with a nRF52832 and have come to similar conclusions based on our testing. If this ticket gets moved to private, we'd be interested to know if a solution is found. Also, if we find a solution for us, we'll report it back here as well.

[schumac]

Are you using MCUBoot? 
I found this suspect line in "mcuboot/zephyr/.config" in the build output directory. 

# CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC is not set
CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=y

If MCU boots settings are overriding project.conf (or project.conf settings failing to override MCUBoot settings) it would make sense with the symptoms (debugger side-steps or uses internal clock) then post-boot it works with the RC oscillator source. 

I had an old board revision laying around with an LFC crystal as the only schematic change - and it booted right up. 

[schumac]

I have confirmed that that line is the culprit - disabling MCUBoot entirely causes the application to start working again. 

Would definitely like some guidance from Nordic on how I can use MCUBoot with only the internal RC oscilator - as our application requires buttonless DFU support.

I could go in and try messing with the MCUBoot settings in the /opt/nordic directory - but everyone working on the firmware would have to modify their MCUBoot config the same way, and redo it every time we reinstall or update the SDK.  

[dejans]

Hi,

schumac said:

Would definitely like some guidance from Nordic on how I can use MCUBoot with only the internal RC oscilator - as our application requires buttonless DFU support.

You might need to include this configuration line:

CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_MAX_SKIP=0

You can get more information by reading about this Zephyr issue and relevant PR.

Best regards,
Dejan

[schumac]

Yep - I saw that thread - I believe that is a different issue - MCUBoot builds fine. I tried it anyways, and had no effect. The built

.config file remained unchanged and still was referencing a (non-existent) external crystal. 

[schumac]

I can confirm this also occurs with the newest nRF SDK version (2.4.1) with the newest toolchain (2.4.0), the xtal crystal is y selected - preventing boot when not connected to a debugger. 

[dejans]

Hi,

In case you use nrf52840-DK, XTAL needs to be disabled. This can be done with CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n. You could try adding this option to your prj.conf file.

Could you show how (non-existent) external crystal is referenced in your .config file?

Best regards,
Dejan

[schumac]

with these values in the prj.conf:

# LFC oscilator

CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y
CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_MAX_SKIP=0

These values end up in the (build output directory)/mcuboot/zephyr/.config

# CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC is not set
CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=y

I would expect the built MCUBoot to defer to the prj.conf on its clock source - I couldnt find any MCUBoot configuration options to explicitly specify its LFC source. 

This issue is impossible to functionally test on a DK - as the DK has the external crystal hardware on board. It will always boot on a DK because MCUBoot will use the external crystal, and then the application will use the RC oscillator. 

To surface this issue on a DK you would need to desolder the 32kHz external crystal. 

What can be seen without access to a board without a 32kHZ clock is the build artifacts that are referencing an external clock when the external clock has been explicitly disabled by the prj.conf. 

[schumac]

Minimal reproducible example here:

NCS 2.4.1

Hello world example

added 
CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_BOOTLOADER_MCUBOOT=y

to prj.conf

Built MCUBoot has:
# CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC is not set
CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=y

In its .config. 

3386.hello_world.zip

[dejans]

Hi,

You could try adding CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n to your MCUboot configuration file.

Best regards,
Dejan