Resetting system after enabling internal RC (Zephyr)

[Deri]

Hi,

I am using a custom board that uses Arm Cortex-A7 and embedding an nRF52840, There is no external low-frequency crystal 32kHz connected to the nrf52 chip, so I've enabled the internal RC by

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_20PPM=y

CONFIG_UART_CONSOLE=y

in prj.conf and added nrf52840dk_nrf52840.overlay to my project.

&uart0 {
	status = "okay";
	current-speed = <19200>;
	tx-pin = <6>;
	rx-pin = <8>;
};

then compiled direct_test_mode example and flashed it using j-link. the custom board starts booting up continuously and showing the below message:

*** Booting Zephyr OS build zephyr-v2.4.0-198-ga4ead9805140  ***
Starting Direct Test Mode example
P0.31 set to high & P0.2,P0.29 set to low.
ASSERTION FAIL [r >= 0] @ WEST_TOPDIR/zephyr/drivers/sensor/nrf5/temp_nrf5.c:61
E: r0/a1:  0x00000004  r1/a2:  0x0000003d  r2/a3:  0x00000001
E: r3/a4:  0x00002761 r12/ip:  0x00000000 r14/lr:  0x000043eb
E:  xpsr:  0x61000000
E: Faulting instruction address (r15/pc): 0x000086c0
E: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
E: Current thread: 0x20000410 (unknown)
E: Resetting system
*** Booting Zephyr OS build zephyr-v2.4.0-198-ga4ead9805140  ***
Starting Direct Test Mode example

Any suggestions to solve this issue?

[Simon]

It seems like this assert was triggered. Can you check what onoff_request() returned? Which one of these? See zephyr\lib\libc\minimal\include\errno.h.

I'm not too familiar with this issue and what the assert may be caused by, but I will look into it/ask internally.

Best regards,

Simon

[Deri]

Hi,

r = onoff_request(data->clk_mgr, &cli)

It has returned 0 for the first time and has returned -5 for the second time and this triggered the macro assert

EIO 5       /* I/O error */

I've also flashed the same FW on nRF52840 DK (PCA10056) and it starts showing the same error and resetting continuously.

[Simon]

I talked to a colleague that tried to enable RC on a chip with a defect XTAL. He told me that NCS would automatically detect this and choose the RC oscillator. Could you try to disable/comment out these:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_20PPM=y

and see if it works.

Best regards,

Simon

[Deri]

When disabling these settings, the Zephyr OS on the custom board doesn't boot up at all, it doesn't show anything on the terminal,

of course, I've enabled the below to see the data on my terminal.

CONFIG_UART_CONSOLE=y

 

any other suggestions?

[Deri]

Is there any update about my issue?

[Simon]

I've been quite busy lately, my apologies for that. I will prioritize your issue tomorrow and try to get to the bottom of it.

Best regards,

Simon

[Simon]

I'm not sure why you're not seeing the serial log. Are you able to use RTT logging?

Could you try to debug your device (e.g. by using Ozone), to see if everything behaves as expected? 

What do you get if you run nrfjprog --memrd 0x40000418 (read this register).

I don't have access to an nRF52 device without/with a defect XTAL, so I'm not able to test this myself. Tomorrow I'll get hold of one and do some testing.

Best regards,

Simon

[Deri]

# nrfjprog --memrd 0x40000418
0x40000418: 00010000 |....|

I will be on vacation for three days and I will start debugging it by Ozone when coming back.

[Simon]

I'm not sure what's causing this behaviour, I've reported your issue internally. I'll keep you updated

Best regards,

Simon

[Deri]

I am still waiting for any progress on solving this matter, Is there any good news?

[Simon]

I'll ask internally if there has been any progress on this. However, I can see that only the nR5340 PDK is listed under Requirements in the DTM Documentation, so it may be that the nRF52840DK is not sufficiently tested. I was able to get internal RC to work with the BLE peripheral_lbs sample, so it seems like this is specific to the DTM sample.

Best regards,

Simon

[Simon]

There seem to be some problems with the calibration of the RC oscillator when requesting the HFCLK. I tried to set a break point at clock_control_nrf.c-->set_starting_state-->err = -EPERM, and it was triggered. Here is the call stack:

I will continue to investigate.

I am really sorry for the slow progress on this issue. 

Best regards,

Simon