nRF52: update from 0.33 -> 0.34 causes 500x idle-current

[perttierkkila]

For ultra-low power applications where all peripherials are disabled and usually under 1.5uA SystemON currents, update to 0.34 was a bad mistake which caused 600uA idle current. After debugging, something keeps requesting HF-clock.

I tried to check diffs between 0.33 and 0.34 and I can't find any changes related to nRF52-parts. The problem is caused under initAll()-code. I tried to dig that part also but no luck as it goes to compiler-part.

Example code:

func main() {
	arm.EnableIRQ(uint32(nrf.IRQ_RTC1)) // workaround to keep IRQs running, already fixed in dev

	led := machine.P0_20
	led.Configure(machine.PinConfig{Mode: machine.PinOutput})
	for {
		led.Set(nrf.CLOCK.HFCLKSTAT.Get()>>16 == 1)
		time.Sleep(10 * time.Millisecond)
		led.Low()
		time.Sleep(500 * time.Millisecond)
	}
}

Serial, GC and scheduler disabled, flashing with command:
tinygo flash -size=short -scheduler=none -gc=none -serial=none -target=pca10040 -programmer command main.go

Output:

• 0.34: led blinks, current 600uA+ (led uses minimal current compared to HF-clock)
• 0.33: no blinking, current under 1.5uA

Also tried to play with -opt values, no effect. Except -opt=0 which keeps current under 1.5uA but code is not running either. Any ideas which causes this issue?

[sago35]

@aykevl Please give some hints.

[aykevl]

How do I reproduce this issue?
It makes sense that HFCLK is running while the code is running. So I think when reading from this register, it will always be set to "1".

I have the following test code, flashed on a PCA10056:

package main

import (
	"device/nrf"
	"machine"
	"time"
)

func main() {
	led := machine.LED
	led.Configure(machine.PinConfig{Mode: machine.PinOutput})
	for {
		led.Set(nrf.CLOCK.HFCLKSTAT.Get()>>16 == 1)
		time.Sleep(500 * time.Millisecond)
		led.Low()
		time.Sleep(500 * time.Millisecond)
	}
}

It blinks in both v0.33.0 and v0.34.0.

[aykevl]

After debugging, something keeps requesting HF-clock.

What do you mean by this? After running tinygo gdb?
Yes, the chip will continue to use lots of current after doing on-chip debugging. The only way to get to normal (low current) behavior is by power cycling. This is a hardware limitation, not a TinyGo bug.

[perttierkkila]

You must use option -serial=none to test actual consumption. Default setting with UART always requires HF-clock and hides a problem.

I just tried to find issues with gdb, no luck. Actual tests were done in standard-mode with option -serial=none