Bug in NCS v1.7.1 with 32kHz RC Oscillator and MCUboot enabled

RE: Bug in NCS v1.7.1 with 32kHz RC Oscillator and MCUboot enabled

tesc — Tue, 10 Sep 2024 14:20:44 GMT

Hi,

Thank you for sharing a link to the thread with the issue you are currently facing. Please continue the discussion in that new thread.

If you see any similarities between the issue you are currently facing and the issues discussed in this older thread, then please link to this thread from the new one, and describe what are the similarities.

Regards,
Terje

RE: Bug in NCS v1.7.1 with 32kHz RC Oscillator and MCUboot enabled

fafeyto — Tue, 10 Sep 2024 10:26:09 GMT

https://devzone.nordicsemi.com/f/nordic-q-a/114520/nrf52832-dfu-ble-with-rc-oscillator

I have similar problem but could not fixed.

RE: Bug in NCS v1.7.1 with 32kHz RC Oscillator and MCUboot enabled

Droidik — Thu, 05 Sep 2024 18:13:36 GMT

What exactly do you mean?
The solution is clearly written in the last response + it has been fixed over 3 years ago.

RE: Bug in NCS v1.7.1 with 32kHz RC Oscillator and MCUboot enabled

fafeyto — Thu, 05 Sep 2024 13:31:16 GMT

I am having the same problem. Any progress?

RE: Bug in NCS v1.7.1 with 32kHz RC Oscillator and MCUboot enabled

Droidik — Thu, 25 Nov 2021 17:00:18 GMT

"We've not noticed anything yet after a week or two."
Thank you for sharing this helpful info, I'll probably also solve it this way.

"The temp_nrf5 files doesn't seem to handle calibration"
No, it does not directly, but the calibration code needs to sample temperature from nrf's internal temperature sensor, so that's the reason.

Yes, the root cause is that the calibration now requires a multithreading support, but the dependency between the CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION and CONFIG_MULTITHREADING config options is not defined in the code.
It works in app builds because CONFIG_MULTITHREADING is turned on by default and it doesn't work in mcuboot builds because mcuboot's config explicitly disables it 🙂

RE: Bug in NCS v1.7.1 with 32kHz RC Oscillator and MCUboot enabled

optimisedpd — Wed, 24 Nov 2021 19:45:11 GMT

Yes, I think (although only intuitively) that the RC clock accuracy in MCUBoot shouldn't be an issue. But could be wrong. We've not noticed anything yet after a week or two.

I certainly think what you found could solve it - but maybe not the root cause. I think the root cause is more likely to be the calibration routine as Nordic said this is what changed, and it not being designed to support single threaded applications.

Similar to this ticket, but for things to do with mutex/locks as in the error above instead of sleep;

devzone.nordicsemi.com/.../zephyr-build-smp_svr-for-thingy52-fails

RE: Bug in NCS v1.7.1 with 32kHz RC Oscillator and MCUboot enabled

Droidik — Wed, 24 Nov 2021 19:37:18 GMT

Thank you very much for the update!
Yes, I mentioned there that it isn't recommended, because the Zephyr docs say so: "If calibration is disabled when RC is used for low frequency clock then accuracy of the low frequency clock will degrade. Disable on your own risk.".

This makes sense for a functionality that requires higher precision clock like BLE, but I guess it's OK to use it in mcuboot (that's only my impression - feel free to correct me).

I think I found the problem - https://github.com/mcu-tools/mcuboot/blob/main/boot/zephyr/Kconfig#L682

RE: Bug in NCS v1.7.1 with 32kHz RC Oscillator and MCUboot enabled

optimisedpd — Wed, 24 Nov 2021 19:21:40 GMT

I also filed a private support case with Nordic and got some more info;

Okay, so it might not be due to a bug after all, but rather that the calibration routine for the 32kHz clock was changed (in nRFConnect SDk v1.6.0 I think). Basically, the 32kHz requires a calibration routine that depends on multithreading. So you will need to enable multithreading or disable the calibration in the sub-image that's not compiling. The temp_nrf5 files doesn't seem to handle calibration, but they do require multithreading, so please try enabling that in your application.

I would think one of the configs CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=n or CONFIG_MULTITHREADING=y would be sufficient here

I ended up solving with CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=n to avoid the size overhead of multithreading. However someone on the Zephyr bug does say this isn't recommended. I'm not sure why but will post there.

Note: this only needs to be set for the MCUBOOT image, not the main image, i.e. adding to a \child_image\mcuboot.conf as per https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_multi_image.html which then merges with the default MCUBOOT configuration.

RE: Bug in NCS v1.7.1 with 32kHz RC Oscillator and MCUboot enabled

Droidik — Wed, 24 Nov 2021 19:13:47 GMT

Identical (or very similar) bug is also tracked here - https://github.com/zephyrproject-rtos/zephyr/issues/40538

RE: Bug in NCS v1.7.1 with 32kHz RC Oscillator and MCUboot enabled

tesc — Fri, 12 Nov 2021 13:33:07 GMT

Hi,

Yes, I think it would definitely be best to solve the build issue with the RC clock. The issue has been reported internally, and we are looking for a solution.

Regards,
Terje

RE: Bug in NCS v1.7.1 with 32kHz RC Oscillator and MCUboot enabled

optimisedpd — Mon, 08 Nov 2021 14:04:32 GMT

I later found the _SYNTH clock causes us issues with provisioning, so maybe this isn't the best approach! It may be better to solve the build issues with the _RC clock.