Most efficient way to delay a few microseconds on nrf52840

RE: Most efficient way to delay a few microseconds on nrf52840

Hung Bui — Wed, 30 Oct 2024 09:26:23 GMT

Hi jthlim,

I agree. I will forward this internally. Even it's only applied for short delay, I think there is many use cases that get benefit from this lower power consumption wait. Will let you know when I have a feedback.

RE: Most efficient way to delay a few microseconds on nrf52840

jthlim — Mon, 28 Oct 2024 16:33:39 GMT

As I mentioned in my original post, yes, any moderate time you should use something other than a busy loop. My use case is just for 5us. I'm also using DCDCEN.

In your tests, if you invert a and b, you're going to have different power consumption -- that's completely expected. udiv clock cycles from 2-12 cycles on the M4, so your decode/fetch will be way more active when it's 2 cycles per instruction rather than 12.

Optimization is currently at -O2, and no intention to change this for my project. It produces the following:

00027534 <_ZN9Nrf5Clock11DelayMicrosEm>:
27534: f04f 31ff mov.w r1, #4294967295 @ 0xffffffff
27538: 2201 movs r2, #1
2753a: fbb1 f3f2 udiv r3, r1, r2
2753e: fbb1 f3f2 udiv r3, r1, r2
27542: fbb1 f3f2 udiv r3, r1, r2
27546: fbb1 f3f2 udiv r3, r1, r2
2754a: fbb1 f3f2 udiv r3, r1, r2
2754e: 3801 subs r0, #1
27550: d1f3 bne.n 2753a <_ZN9Nrf5Clock11DelayMicrosEm+0x6>
27552: 4770 bx lr

At the end of the day, it's not a huge difference as I'm only using it for tiny delays; but afaik no reason not to do it this way :)

RE: Most efficient way to delay a few microseconds on nrf52840

Hung Bui — Mon, 28 Oct 2024 15:47:27 GMT

Hi jthlim,
Thanks for the interesting post. I can confirm what you reported. I have checked a little bit internally. What I was told is that the consumption of the CPU depends largely on the what's put on the bus and if the instruction is executed from CACHE or RAM.
The number we provided in the specification was measured when the CPU running CoreMark test, which I assume involve random values on the bus.

When I invert the value of a and b in your function, I can already see that the power consumption jumped drastically to over what's the nrf_delay_us() consume. You can see in the attached graph, the function with inverted a and b is called right after yours DelayMicros:

The next one is when I keep b=1 and a=0xFFFF, the power consumption is much lower and near what you have.

We can clearly see that the value on the bus is really affecting the power consumption.

Have you tried to test with different optimization level to see if the power consumption is changed and if the timing is consistent ? I thing the timing may not be the same when you change the optimization level.

How long do you need the delay ? If it's >500us, using a TIMER and put the CPU to IDLE maybe a better option.

RE: Most efficient way to delay a few microseconds on nrf52840

hmolesworth — Sat, 26 Oct 2024 20:30:05 GMT

Nice post! I confirm your findings for reduced power consumption on a nRF52832 which I happen to have running with nothing attached to any pins and no errata workarounds; IAR compiler. This is useful.

Conditions are 3.3VDD supply, DCD enabled

void TestDelayMicros(void)
{
   NRF_POWER->DCDCEN = 1;
   while(1)
   {
       DelayMicros(1000);  // 1.96mA with VDD supply 3.3V, DCDCEN enabled
     //nrf_delay_us(1000); // 2.61mA with VDD supply 3.3V, DCDCEN enabled
   }
}