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

[EugeneBrod]

Hello, I've been puzzled with a strange issue that I was hoping to be helped with.

I am noticing differing behavior in the external high frequency clock when flashing with nrfjprog directly compared to using flashing through Segger Ozone.

First off, let me show the difference. I've set up my clock to generate an interrupt every 16,666us. Here is a trace I grabbed with my logic analyzer when I flashed through Ozone.

And below is a trace of the same binary, flashed with...

nrfjprog --program nrf52840_xxaa.hex --family NRF52 --sectorerase;

nrfjprog --reset;

You can see that flashing my hardware directly with nrfjprog results in an additional 12us to the clock interval.

Additional detail: The "correct" flashing configuration that Ozone imparts is retained after a hardware reset. However when I run nrfjprog --reset, the issue affecting the clock returns.

I'm not sure if this would help with my case but here are the logs from the Ozone console that list the specific interactions with the processor. 

Debug.Start();
Device "NRF52840_XXAA" selected.
InitTarget() start
InitTarget() end
Found SW-DP with ID 0x2BA01477
DPIDR: 0x2BA01477
CoreSight SoC-400 or earlier
Scanning AP map to find all available APs
AP[2]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x24770011)
AP[1]: JTAG-AP (IDR: 0x02880000)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FF000
CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
Found Cortex-M4 r0p1, Little endian.
FPUnit: 6 code (BP) slots and 2 literal slots
CoreSight components:
ROMTbl[0] @ E00FF000
[0][0]: E000E000 CID B105E00D PID 000BB00C SCS-M7
[0][1]: E0001000 CID B105E00D PID 003BB002 DWT
[0][2]: E0002000 CID B105E00D PID 002BB003 FPB
[0][3]: E0000000 CID B105E00D PID 003BB001 ITM
[0][4]: E0040000 CID B105900D PID 000BB9A1 TPIU
[0][5]: E0041000 CID B105900D PID 000BB925 ETM
Connected to target device.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
Elf.GetBaseAddr(); // returns 0x0
Target.ReadU32 (0x00000000); // returns 0x4, data is 0x20040000
Target.SetReg ("SP", 0x20040000);
Elf.GetEntryPointPC(); // returns 0xDFF0
Target.SetReg ("PC", 0xDFF0);
J-Link: Flash download: Bank 0 @ 0x00000000: Skipped. Contents already match
Elf.GetBaseAddr(); // returns 0x0
Target.ReadU32 (0x00000000); // returns 0x4, data is 0x20040000
Target.SetReg ("SP", 0x20040000);
Elf.GetEntryPointPC(); // returns 0xDFF0
Target.SetReg ("PC", 0xDFF0);
Startup complete (PC=0x000006E0)
Executed J-Link command "SetRTTAddr 0x20002044"
Debug.Continue();

I would appreciate any help. Thanks.

[EugeneBrod]

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.

[Håkon Alseth]

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