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]

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. 

[Vidar Berg]

Thank you for the update. I’m happy to hear that you’ve found a temporary workaround. I think this issue should be investigated further on our end, so I’ll report it as a bug internally. I’ll update the thread as soon as I know more.

[alexdr5398]

Great thanks a lot. If you need me to provide more info for debugging, then just let me know. 

[Vidar Berg]

Thank you. One more follow up question, are you using the Watchdog peripheral in your application? The watchdog will automatically request the RCOSC if active on startup and it may potentially be relevant to the issue.

[alexdr5398]

I did have the watchdog peripheral enabled in both mcuboot and the main app. I've tried disabling it in both and seems like the behaviour is the same from what I can tell. I still require the start_lfclk sys_init for it to work properly. 

[Vidar Berg]

Thank you for re-testing this again also without the WDT active. I will add this to my bug report.