Upgrading through DFU Target results in MPSL Assertion (112, 2142)

[Peter Maxwell Warasila]

Using ncs 2.1.2 on nrf52840. Softdevice controller, bluetooth mesh and bluetooth gatt coexisting application.

I have been having an issue attempting to perform DFU using the dfu_target interface on our nrf52840. For whatever reason, an MPSL assertion is being raised during this process. It is more consistently raised the larger I make the buffer passed through dfu_target_mcuboot_set_buf(). I've enabled the maximum (debug) logging from all the MPSL sources in KConfig, but I have not seen any additional logs. CONFIG_SOC_FLASH_NRF_RADIO_SYNC_MPSL is enabled, so my understanding is that should deal with any synchronization required. A log is shown below.

[00:01:26.549,102] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x0007e000
[00:01:27.718,017] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x0007f000
[00:01:28.861,694] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x00080000
[00:01:29.995,269] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x00081000
[00:01:31.164,489] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x00082000
[00:01:32.339,294] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x00083000
[00:01:33.468,994] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x00084000
[00:01:34.672,882] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x00085000
[00:01:35.801,696] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x00086000
[00:01:36.970,489] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x00087000
[00:01:38.137,115] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x00088000
[00:01:39.272,125] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x00089000
[00:01:40.406,616] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x0008a000
[00:01:41.575,500] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x0008b000
[00:01:42.738,739] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x0008c000
[00:01:43.869,415] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x0008d000
[00:01:45.040,130] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x0008e000
[00:01:46.189,117] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x0008f000
[00:01:47.317,932] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x00090000
[00:01:48.473,114] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x00091000
[00:01:49.641,021] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x00092000
[00:01:50.785,522] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x00093000
[00:01:51.945,953] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x00094000
[00:01:53.111,816] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x00095000
[00:01:54.249,938] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x00096000
[00:01:55.416,595] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x00097000
[00:01:56.581,695] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x00098000
[00:01:57.776,275] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x00099000
[00:01:58.952,484] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x0009a000
[00:02:00.088,195] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x0009b000
[00:02:01.219,482] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x0009c000
[00:02:02.381,866] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x0009d000
[00:02:03.550,964] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x0009e000
[00:02:04.718,780] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x0009f000
[00:02:05.891,052] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000a0000
[00:02:07.029,693] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000a1000
[00:02:08.200,744] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000a2000
[00:02:09.368,774] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000a3000
[00:02:10.502,593] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000a4000
[00:02:11.673,065] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000a5000
[00:02:12.861,755] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000a6000
[00:02:13.996,246] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000a7000
[00:02:15.163,269] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000a8000
[00:02:16.329,406] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000a9000
[00:02:17.466,461] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000aa000
[00:02:18.637,481] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000ab000
[00:02:19.793,518] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000ac000
[00:02:20.917,968] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000ad000
[00:02:22.090,728] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000ae000
[00:02:23.252,349] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000af000
[00:02:24.394,104] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000b0000
[00:02:25.563,507] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000b1000
[00:02:26.725,860] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000b2000
[00:02:27.947,998] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000b3000
[00:02:29.115,051] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000b4000
[00:02:30.250,396] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000b5000
[00:02:31.415,008] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000b6000
[00:02:32.586,853] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000b7000
[00:02:33.717,224] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000b8000
[00:02:34.886,779] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000b9000
[00:02:36.052,154] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000ba000
[00:02:37.188,446] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000bb000
[00:02:38.356,781] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000bc000
[00:02:39.524,169] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000bd000
[00:02:40.659,301] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000be000
[00:02:41.822,753] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000bf000
[00:02:43.003,967] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000c0000
[00:02:44.174,316] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000c1000
[00:02:45.343,017] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000c2000
[00:02:46.472,106] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000c3000
[00:02:47.609,558] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000c4000
[00:02:48.774,597] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000c5000
[00:02:49.943,969] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000c6000
[00:02:51.076,110] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000c7000
[00:02:52.244,079] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000c8000
[00:02:53.388,488] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000c9000
[00:02:54.521,545] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000ca000
[00:02:55.689,453] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000cb000
[00:02:56.856,262] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000cc000
[00:02:57.995,483] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000cd000
[00:02:59.164,947] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000ce000
[00:03:00.331,756] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000cf000
[00:03:01.470,123] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000d0000
[00:03:02.640,655] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000d1000
[00:03:03.795,196] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000d2000
[00:03:04.929,748] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000d3000
[00:03:06.175,964] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000d4000
[00:03:07.311,157] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000d5000
[00:03:08.481,323] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000d6000
[00:03:09.646,759] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000d7000
[00:03:10.788,269] <dbg> STREAM_FLASH: stream_flash_erase_page: Erasing page at offset 0x000d8000
[00:03:10.908,721] <err> mpsl_init: MPSL ASSERT: 112, 2142
ASSERTION FAIL [z_spin_lock_valid(l)] @ WEST_TOPDIR/zephyr/include/zephyr/spinlock.h:142
        Recursive spinlock 0x2000a7f0
[00:03:10.908,813] <err> os: ***** HARD FAULT *****
[00:03:10.908,813] <err> os:   Fault escalation (see below)
[00:03:10.908,843] <err> os: ARCH_EXCEPT with reason 4

[00:03:10.908,843] <err> os: r0/a1:  0x00000004  r1/a2:  0x0000008e  r2/a3:  0x00000003
[00:03:10.908,874] <err> os: r3/a4:  0x0000008e r12/ip:  0x00000000 r14/lr:  0x0005d773
[00:03:10.908,874] <err> os:  xpsr:  0x61000018
[00:03:10.908,905] <err> os: Faulting instruction address (r15/pc): 0x000637dc
[00:03:10.908,935] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
[00:03:10.908,935] <err> os: Fault during interrupt handling

[00:03:10.908,966] <err> os: Current thread: 0x20003c88 (MPSL Work)
[00:03:11.283,386] <err> fatal_error: Resetting system

Since the MPSL is completely opaque, I really have no idea what's going on here. My best guess is that some time critical behavior is being violated, but I am not sure what. I'm also not sure what to do about it, since the flash erase and write times are essentially out of my control.

[Peter Maxwell Warasila]

Hieu,

Of course. We started with the Mesh and Peripheral Coexistence sample. We replaced the light button service with our own service (which is fairly similar to the NUS), replaced the mesh model with our own model, added a serial connection to the host processor on our system, and enabled CONFIG_DFU_TARGET_MCUBOOT=y. We then use serial commands to write packets of the update image to flash. These are handled by an application thread which is reading from a ring buffer populated using the async serial API.

I want to add that we seem to be having issues with delayable work/timeouts in the async serial uarte driver and the bluetooth mesh extended advertiser. Essentially, it seems like the timeout takes an entire RTC counter wrap around to occur. I'm going to trial using the SysTick as a source to see if the behavior is within the RTC timer driver. It may be related, but I don't see the MPSL assertion when we are not writing to flash.

[Hieu]

Peter,

I plan to replicate your issue here and try some debugging. It seems I will make do with the Mesh and Peripheral Coexistence sample as is then.

Could you please give some more details on the "added a serial connection" part? Which peripheral (1/2/3) did you use, and what Kconfig and DTS config did you set it up with?

If you feel like it can be quite complicated to replicate your issue, please let me know if you want to send us your project.

[Peter Maxwell Warasila]

Our serial connection is over UART0. The relevant KConfig used is shown below.

CONFIG_UART_ASYNC_API=y
CONFIG_UART_0_NRF_HW_ASYNC=y
CONFIG_UART_0_NRF_HW_ASYNC_TIMER=2

We are currently using the default DTS configuration for UART0 for the UBX_BMD345EVAL_NRF52840 board.

If replicating the issue is particularly difficult for you, send me an email with how best we can securely share our project with you. It might be hard to support the host side interaction of the serial connection, but we may be able to skip over some messages.

[Peter Maxwell Warasila]

So I've had success today after switching from the nrf RTC timer to the systick for the system tick source. Is there a known issue with the RTC timer in ncs 2.1.2?

[Hieu]

Sorry but I am not clear about/familiar with what you changed here. Could you please give some further details?

[Peter Maxwell Warasila]

Essentially, I added the following to our prj.conf file. We had no issues with the debugger connected after making this change. However I'm now running into an issue where the kernel tick count is not being updated until the RTT is connected. Very strange. Either way, I would have expected the RTC timer to work correctly out of the box. However, there seems to be an issue where timeouts can be evaluated on the 2^24 - 1 tick after the current one, for whatever reason. It appears something like that must have been interfering with the MPSL as well, it would seem.

CONFIG_NRF_RTC_TIMER=n
CONFIG_CORTEX_M_SYSTICK=y
CONFIG_SYS_CLOCK_TICKS_PER_SEC=10000
CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=64000000

[Hieu]

By "kernel tick count is not being updated," do you mean k_uptime_get() and k_uptime_ticks() return 0?

[Peter Maxwell Warasila]

Not exactly. Timers are not executed in real time. k_uptime_get() reflects that the ticks counted by the system are less and are proportional to the timer execution. For example, a 5 second timer will take ~40 seconds to execute, and k_uptime_get() between those two times reflects that the kernel ticks have only advanced 5 seconds.

Once RTT is connected to read log messages, the ticks advance normally. This appears to continue after disconnection of the RTT as well.

This is all specifically while using the SysTick as the timer driver.

[Hieu]

Hi Peter,

The behavior you described are very strange. I will need to forward this to our R&D team. I will do that on Monday for some better attention.

I am having some difficulties reproducing the initial issue on my end. I will see if I can give it some more tries this weekend, as that might help R&D help faster.

Hieu

[Peter Maxwell Warasila]

Hieu,

I have been doing some testing with the Zephyr community on this issue and I think we have a good idea of what was originally going on when using the nrf_rtc_timer.c driver for the system timer. Using tests/kernel/timer/timer_behavior with ncs 2.2.0, the timer train test fails on our hardware, the nrf52840dk_nrf52840 dev kit, and the ubx_bmd345eval_nrf52840 evaluation kit. In our application, whenever we saw what seemed to be a missed timeout, it looked like it was handled nearly one full counter rollover late (~512 seconds). This pointed to some missed rollover behavior.

I ran test/kernel/timer/timer_behavior using latest zephyr instead of the version packaged with ncs 2.2.0, and the timer train test passed. I then ran a diff between the latest zephyr and ncs 2.2.0 versions of nrf_rtc_timer.c and discovered that there are differences, and they seem to deal with exactly this sort of issue in terms of setting an alarm when the requested cc_val is in the past or the next tick. See diff below.

diff --git a/drivers/timer/nrf_rtc_timer.c b/C:/Users/Peter/ncs/v2.2.0/zephyr/drivers/timer/nrf_rtc_timer.c
index b3b2cadeae..a7587f3366 100644
--- a/drivers/timer/nrf_rtc_timer.c
+++ b/C:/Users/Peter/ncs/v2.2.0/zephyr/drivers/timer/nrf_rtc_timer.c
@@ -42,7 +42,6 @@ BUILD_ASSERT(CHAN_COUNT <= RTC_CH_COUNT, "Not enough compare channels");
 static volatile uint32_t overflow_cnt;
 static volatile uint64_t anchor;
 static uint64_t last_count;
-static bool sys_busy;
 
 struct z_nrf_rtc_timer_chan_data {
 	z_nrf_rtc_timer_compare_handler_t callback;
@@ -234,7 +233,6 @@ static uint32_t set_absolute_alarm(int32_t chan, uint32_t abs_val)
 	uint32_t now2;
 	uint32_t cc_val = abs_val & COUNTER_MAX;
 	uint32_t prev_cc = get_comparator(chan);
-	uint32_t tick_inc = 2;
 
 	do {
 		now = counter();
@@ -253,16 +251,12 @@ static uint32_t set_absolute_alarm(int32_t chan, uint32_t abs_val)
 			k_busy_wait(19);
 		}
 
-		/* RTC may not generate event if CC is set for 1 tick from now.
-		 * Because of that if requested cc_val is in the past or next tick,
-		 * set CC to further in future. Start with 2 ticks from now but
-		 * if that fails go even futher. It may fail if operation got
-		 * interrupted and RTC counter progressed or if optimization is
-		 * turned off.
+		/* If requested cc_val is in the past or next tick, set to 2
+		 * ticks from now. RTC may not generate event if CC is set for
+		 * 1 tick from now.
 		 */
 		if (counter_sub(cc_val, now + 2) > COUNTER_HALF_SPAN) {
-			cc_val = now + tick_inc;
-			tick_inc++;
+			cc_val = now + 2;
 		}
 
 		event_clear(chan);
@@ -548,41 +542,6 @@ void z_nrf_rtc_timer_chan_free(int32_t chan)
 }
 
 
-int z_nrf_rtc_timer_trigger_overflow(void)
-{
-	uint32_t mcu_critical_state;
-	int err = 0;
-
-	if (!IS_ENABLED(CONFIG_NRF_RTC_TIMER_TRIGGER_OVERFLOW) ||
-	    (CONFIG_NRF_RTC_TIMER_USER_CHAN_COUNT > 0)) {
-		return -ENOTSUP;
-	}
-
-	mcu_critical_state = full_int_lock();
-	if (sys_busy) {
-		err = -EBUSY;
-		goto bail;
-	}
-
-	if (counter() >= (COUNTER_SPAN - 100)) {
-		err = -EAGAIN;
-		goto bail;
-	}
-
-	nrf_rtc_task_trigger(RTC, NRF_RTC_TASK_TRIGGER_OVERFLOW);
-	k_busy_wait(80);
-
-	uint64_t now = z_nrf_rtc_timer_read();
-
-	if (err == 0) {
-		sys_clock_timeout_handler(0, now, NULL);
-	}
-bail:
-	full_int_unlock(mcu_critical_state);
-
-	return err;
-}
-
 void sys_clock_set_timeout(int32_t ticks, bool idle)
 {
 	ARG_UNUSED(idle);
@@ -594,10 +553,6 @@ void sys_clock_set_timeout(int32_t ticks, bool idle)
 
 	ticks = (ticks == K_TICKS_FOREVER) ? MAX_TICKS : ticks;
 	ticks = CLAMP(ticks - 1, 0, (int32_t)MAX_TICKS);
-	/* If timeout is set to max we assume that system is idle and timeout
-	 * is set to forever.
-	 */
-	sys_busy = (ticks < (MAX_TICKS - 1));
 
 	uint32_t unannounced = z_nrf_rtc_timer_read() - last_count;
 
@@ -677,7 +632,8 @@ static int sys_clock_driver_init(const struct device *dev)
 	}
 
 	uint32_t initial_timeout = IS_ENABLED(CONFIG_TICKLESS_KERNEL) ?
-		MAX_TICKS : (counter() + CYC_PER_TICK);
+		(COUNTER_HALF_SPAN - 1) :
+		(counter() + CYC_PER_TICK);
 
 	compare_set(0, initial_timeout, sys_clock_timeout_handler, NULL);
 

I'm not positive that this is the sole reason for this behavior, but it seems to be a likely candidate. There may be other differences in how ncs 2.2.0 deals with the rtc timer which I am unaware of.

As far as the issues with the SysTick before connecting the RTT, I'm still not sure what's going on. However, running the code on our dev kits did not show the same behavior, so we must have some sort of hardware issue causing that. Maybe there's a debug pin floating or something? I'm not sure what would cause that symptom.

[Peter Maxwell Warasila]

...back to square one it looks like. The test requirements for the timer tick train were reduced, specifically with platforms like nRF in mind. See diff below:

diff --git a/tests/kernel/timer/timer_behavior/src/tick_timer_train.c b/C:/Users/Peter/ncs/v2.2.0/zephyr/tests/kernel/timer/timer_behavior/src/tick_timer_train.c
index 27a90e7a86..368ff74a8a 100644
--- a/tests/kernel/timer/timer_behavior/src/tick_timer_train.c
+++ b/C:/Users/Peter/ncs/v2.2.0/zephyr/tests/kernel/timer/timer_behavior/src/tick_timer_train.c
@@ -132,13 +132,8 @@ ZTEST(timer_tick_train, test_one_tick_timer_train)
 		k_timer_stop(&timers[i].tm);
 	}
 
-	const uint32_t maximum_busy_loops = TEST_SECONDS * 4;
-	/* On some platforms, where the tick period is short, like on nRF
-	 * platforms where it is ~30 us, execution of the timer handlers
-	 * can take significant part of the CPU time, so accept if at least
-	 * one-third of possible busy loop iterations is actually performed.
-	 */
-	const uint32_t acceptable_busy_loops = maximum_busy_loops / 3;
+	const uint32_t expected_busy_loops = TEST_SECONDS*4;
+	const uint32_t acceptable_busy_loops = expected_busy_loops - expected_busy_loops/10;
 
 	zassert_true(busy_loops > acceptable_busy_loops,
 		     "Expected thread to run while 1 tick timers are firing");

That said it looks like the issue is at least partially mitigated in our application with the code pulled in from Zephyr, though not perfectly. I still get occasional timer issues (which are visible through pauses in the serial heartbeat from the radio).

The only workaround I've found so far is to significantly reduce CONFIG_SYS_CLOCK_TICKS_PER_SEC to a value of 2048 or lower.

[Hieu]

Hi Peter,

It seems you are making a lot more progress than I have.

I am a little confused about your newest message. Are you saying that the test with latest main only passes because it was "easier" for nRF chips?

I think the comment in the diff would explain why the test was made more passable, do you not agree?

If I understand correctly, you are saying that the SysTick problem still happens with the latest main branch, however, not as often. Is this right?

I will forward your findings to our R&D team and get further support from them. If there are changes between latest main branch and 2.2.0, it likely means that the topic is under development and has someone actively working on it, so that's a good sign.

---

On the other hand, it seems that you are now very invested into investigating the slowed SysTick. Are you intended on getting SysTick to work reliably when "CONFIG_NRF_RTC_TIMER=n" and considering that a workaround for the original failed DFU issue?

Hieu