nRF52833 + external 32 kHz TCXO: soft reset hangs

[alexdr5398]

I’m working with a custom board based on the nRF52833. It uses an external 32 kHz TCXO (SiT1552) as the LFCLK source.

• In my main Zephyr app I set: CONFIG_CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING=y  and in mcuboot i set CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y. This boots fine if I power cycle the board, but then when the app does a software reboot (sys_reboot(...) or NVIC_SystemReset()), the system hangs indefinitely. Power-cycling causes it to again boot into the primary image normally. 

• If I switch mcuboot to also use EXT_FULL_SWING, then after reset I see the UART log:

  mcuboot: Jumping to the first image slot
  

  but then nothing. I investigated with a debugger and it the app never seems to reach main() or even any SYS_INIT routines. Whenever I break, it's just in the zephyr kernel's idle thread. 

So, to summarize:

• App works with TCXO only if mcuboot uses RC, but any software reboots causes hang.

• If both use TCXO, app never boots.

• If both use RC, then every thing works normally (but i of course want to use the external tcxo). 

Versions:

zephyr: nrfconnect sdk-zephyr v3.5.99
nrf: nrfconnect sdk-nrf v2.6.1

Any help on this is greatly appreciated. 

Thanks

EDIT: I forgot to mention that I have indeed verified that the program is getting past the `lfclk_spinwait` function, so it does seem to be detecting that the clock has started. I placed a breakpoint at `clock_control_nrf.c:540` after the `!nrf_clock_is_running` loop, and it does indeed reach that point. 

[Vidar Berg]

Hello,

I don't have a TCXO to test with here so I can't easily reproduce this, but I assume the reason it hangs is that the LF clock started event is not triggered causing the program to never exit clock_control_nrf.c->lfclk_spinwait() function. You may be able to confirm this by looking at the call stacks.

If I switch mcuboot to also use EXT_FULL_SWING, then after reset I see the UART log:

As a test,  please try and see if you get the same result if you build the app with CONFIG_SYSTEM_CLOCK_NO_WAIT=y.

Best regards,

Vidar

[alexdr5398]

Hi Vidar,

My mistake. I forgot to mention in the original post that I did trying placing a breakpoint at the end of that function (clock_control_nrf.c:540, right after the 'clock_is_running' loop), and it does indeed hit that breakpoint, but then any time I break after that the kernel is just in 'k_cpu_idle' with the thread entry pointed at the idle thread:

CONFIG_SYSTEM_CLOCK_NO_WAIT=y had no effect, i'm assuming this is just skipping that spinwait function?

Thanks for the reply, 
Alex

[alexdr5398]

Small update: 

I have confirmed that I do hit breakpoints in PRE_KERNEL_X SYS_INIT's and in POST_KERNEL SYS_INIT with priority 0, *but not* priority 99. 

Currently narrowing down exactly which sys_init is causing the issue. 

[alexdr5398]

I have confirmed that this breakpoint is hit:

static int test_init() {
	return 0;
}
SYS_INIT(test_init, POST_KERNEL, 79);

but this one never is:

static int test_init() {
	return 0;
}
SYS_INIT(test_init, POST_KERNEL, 80);

[Vidar Berg]

Interesting. You can view the list of init functions here if you're using VS code: 

alexdr5398 said:

CONFIG_SYSTEM_CLOCK_NO_WAIT=y had no effect, i'm assuming this is just skipping that spinwait function?

Correct.

[alexdr5398]

I'm not using vscode unfortunately. do you what command line tool gives access to that info?

I can maybe try to get vscode working for this project.