Hi Carles,

Thanks for the quick response.

1) We're using the latest master.
2) We're building for the nrf52_pca10040. I think we are enabling it: CONFIG_CLOCK_CONTROL_NRF5_K32SRC_XTAL=y
3) TICKLESS_IDLE is enabled, but TICKLESS_KERNEL is disabled.
4) I'm sorry, I can't pinpoint it right now to you. I'm going to investigate further here and report back. We've started experiencing this problem at the start of this week, but we were at a two-week development hiatus before then.
The only thing we added as the watchdog. The watchdog code is as follows:

void wdt_init(uint32_t reload_ms) {

NRF_WDT->CONFIG = 0x01 | 0x08;

NRF_WDT->CRV = (reload_ms / 1000) * 32678;

        SYS_LOG_WRN("%d: %d or %u", reload_ms, NRF_WDT->CRV, NRF_WDT->CRV);

NRF_WDT->INTENSET = WDT_INTENSET_TIMEOUT_Msk;

NRF_WDT->TASKS_START = 1;

}

void wdt_reload(uint8_t channel) {

NRF_WDT->RR[channel] = NRF_WDT_RR_VALUE;

}

I attached our .config to the original gist, it is there at the end now: https://gist.github.com/durub/edda1fbf6a6c8f1c7f88960d26916ddf

I tried just now to reproduce the problem without any of our code (but using our .config), and the problem still persists. Our main is:

void main() {

k_busy_wait(100);

}

We've tested this main using nrf52_pca10040 and our PCB. Sample of the final of the faulty output:

0 0 3

0 0 3

(a lot of equal lines)

0 0 3

0 0 3

0 shell> 30 30 3

30 56 3

I must say that this problem is happening intermittently. Now, the simple main is always working (a lot of successive resets with nrfjprog --reset -f nrf52):

shell> 38 38 3

38 64 3

shell> 38 38 3

38 65 3

shell> 38 38 3

38 64 3

shell> 38 38 3

38 65 3

shell> 38 38 3

38 65 3

shell> 38 38 3

38 64 3

shell> 38 38 3

38 65 3

shell> 38 38 3

38 64 3

shell> 38 38 3

38 64 3

Thanks a lot,

Thiago

2017-08-18 13:37 GMT-03:00 Cufi, Carles <Carles.Cufi@...>:

Hi Thiago,

> -----Original Message-----
> Subject: [Zephyr-users] nRF52832 hardware cycle count freezing at chip
> start
>
> Hi everyone,
>
> We've been having some strange problem lately. When nRF52832 powers up,
> our code starts running, but the hardware cycle count (calling
> k_cycle_get_32(), for example) remains static at zero for some time (one
> to two minutes).
> Therefore, when we call k_sleep or k_busy_wait, the code stops there and
> hangs in the k_busy_wait while loop, as the hardware cycle count is not
> counting.
> After a while, the chip restarts by itself (watchdog wasn't configured
> by this point), and this second time the code runs normally.
>
> To debug this problem, we added a printk inside k_busy_wait's while
> loop: printk("%d %d %d\n", start_cycles, current_cycles,
> cycles_to_wait); Adding this printk lead us to the evidence above:
> 1) that the hardware cycle count is not running the first time;
> 2) that, after a restart (by whom?), the hardware cycle count is normal
> and the code runs just fine.
>
> The serial output and modified k_busy_wait code is here:
> https://gist.github.com/durub/edda1fbf6a6c8f1c7f88960d26916ddf
> The first line of the chip's output is "[exati-watchdog] [DBG]
> watchdog_init: [34m-------------=============Watchdog thread scheduled
> (...)".
> The code hangs just after "Protocol initialized.", where we call
> k_busy_wait.
>
> Can somebody shed some light on this problem? My teammate and I have
> been struggling with it for the last couple days, but no progress so
> far.

Interesting, we haven't heard of this problem before, although there have been some issues with the nRF5x timer driver that we thought we had addressed.

So can you please expand on the following basic info before I try to reproduce:

1) Are you using the latest master or an older release?
2) What board are you building for does it have a 32Khz crystal, and do you enable the 32KHz timer in your .config?
3) Are you enabling TICKLESS_IDLE or TICKLESS_KERNEL? In fact, could you provide your .config file?
4) When did this problem appear if you're using master? There was a commit merged recently that added TICKLESS_KERNEL support for the nrf RTC driver, I wonder if it broke then.

Thanks,

Carles