Attachments (0)
Nordic Case Info
  • Case ID: 279230
Options

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

optimisedpd

Well, this one took me many hours of tracing to track down the root cause, so I hope it helps someone!

Note: I wasn't able to reproduce this directly with a sample included in the nRF Connect SDK. But it happens with my application, based on the "light_ctrl" mesh sample.

It occurs with the following 3-way combination (tested, only if all met);

  • CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
  • CONFIG_BOOTLOADER_MCUBOOT=y
  • nRF Connect SDK v1.7.1 (didn't occur with v1.4.2 I last used)

I also had to enable CONFIG_BT_LL_SW_SPLIT=y  for zephyr controller to be able to fit in the flash of the nRF52833DK I'm using, but not sure if this is related (yes I intend to move to the soft device and know it is now recommended).

To fix I've changed to CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=y

I've found these two issues which appear to have similar failure logs;

https://github.com/zephyrproject-rtos/zephyr/pull/25583

https://devzone.nordicsemi.com/f/nordic-q-a/76899/zephyr-build-smp_svr-for-thingy52-fails

Build error log below

Kevin

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
C:\freelance\git\pt118b_firmware>west build --pristine --board pt118a_nrf52833_3-1_3A --build-dir build-release_pt118a-3-1-3A -- -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=On -DNCS_TOOLCHAIN_VERSION:STRING="NONE"
-- west build: making build dir C:\freelance\git\pt118b_firmware\build-release_pt118a-3-1-3A pristine
-- west build: generating a build system
Including boilerplate (Zephyr base): C:/freelance/ncs/v1.7.1/zephyr/cmake/app/boilerplate.cmake
-- Application: C:/freelance/git/pt118b_firmware
-- Zephyr version: 2.6.99 (C:/freelance/ncs/v1.7.1/zephyr), build: v2.6.99-ncs1-1
-- Found Python3: C:/freelance/ncs/v1.7.1/toolchain/opt/bin/python.exe (found suitable exact version "3.8.2") found components: Interpreter
-- Found west (found suitable version "0.11.1", minimum required is "0.7.1")
-- Board: pt118a_nrf52833_3-1_3A
-- Cache files will be written to: C:/freelance/ncs/v1.7.1/zephyr/.cache
-- Found dtc: C:/freelance/ncs/v1.7.1/toolchain/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
-- Found toolchain: gnuarmemb (C:/freelance/ncs/v1.7.1/toolchain/opt)
-- Found BOARD.dts: C:/freelance/git/pt118b_firmware/boards/arm/pt118a_nrf52833_3-1_3A/pt118a_nrf52833_3-1_3A.dts
-- Generated zephyr.dts: C:/freelance/git/pt118b_firmware/build-release_pt118a-3-1-3A/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: C:/freelance/git/pt118b_firmware/build-release_pt118a-3-1-3A/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: C:/freelance/git/pt118b_firmware/build-release_pt118a-3-1-3A/zephyr/include/generated/device_extern.h
-- Including generated dts.cmake file: C:/freelance/git/pt118b_firmware/build-release_pt118a-3-1-3A/zephyr/dts.cmake
Parsing C:/freelance/ncs/v1.7.1/zephyr/Kconfig
Loaded configuration 'C:/freelance/git/pt118b_firmware/boards/arm/pt118a_nrf52833_3-1_3A/pt118a_nrf52833_3-1_3A_defconfig'
Merged configuration 'C:/freelance/git/pt118b_firmware/prj.conf'
Configuration saved to 'C:/freelance/git/pt118b_firmware/build-release_pt118a-3-1-3A/zephyr/.config'
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Parents
  • 0 in reply to Droidik

    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.

  • 0 in reply to optimisedpd

    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

  • 0 in reply to optimisedpd

    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

  • 0 in reply to optimisedpd

    "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 Slight smile

Reply
  • 0 in reply to optimisedpd

    "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 Slight smile

Children
Terms of service