RE: Differing hfclk behavior when flashing with nrfjprog directly versus nrfjprog via Ozone

Håkon Alseth — Thu, 30 Mar 2023 12:01:39 GMT

Hi,

When you're in debug mode, certain features in hardware are kept alive in sleep as well, such as the supply voltage to the flash and clocks etc, and gives you a base current consumption of around 1.2 mA.

This gives you better timing values compared to actually going into low power mode (ie. sub 10 uA scenario).

If you want to have the same timing on wakeup, you can do this by setting NRF_CLOCK->TASKS_CONSTLAT:

https://infocenter.nordicsemi.com/topic/ps_nrf52840/power.html?cp=5_0_0_4_2_3_0#unique_441713022

However; this has a drawback of drawing ~0.5 mA in sleep (HFCLK will be kept running)

Kind regards,

Håkon

RE: Differing hfclk behavior when flashing with nrfjprog directly versus nrfjprog via Ozone

EugeneBrod — Thu, 30 Mar 2023 03:07:56 GMT

Update: I think I've found the source of the delay. I put the chip into WFE mode while awaiting new interrupts. Turns out, according to https://devzone.nordicsemi.com/f/nordic-q-a/70548/what-is-the-delay-time-from-wfe-to-interrupt, the delay from WFE to interrupt can be 12us, so I think my situation is consistent with my theory. Ozone must have attached to the debugger and cause the WFE to be "faked". I am curious how the debugger is still considered attached even after a hardware reset.