nRF5340 Tickless Idle

[jvr]

Hi

I'm currently evaluating the possibility of using nRF5340 in an upcoming project. As the chip is very new it's easy to understand that all specifications are not yet available. What I'm interested is the current / power consumption in tickless sleep. I would like to measure that using nRF5340-PDK (which I already have). I would need to have resolution of about 1 ms (1/1024 is fine).

I (eventually) did manage to get Zephyr toolchain and Segger Embedded Studio installed on Windows as per instructions, but couldn't figure out how to enable tickless idle. I could only reach current consumption of 1.65 mA (measured from P22, powered with coin cell, as instructed in the ). Curiously the current consumption doesn't seem to be at all by LED duty cycle or sleep time, nor 'nrf only' switch. I've been working on the 'blinky' example.

Is tickless idle supported yet?

Would you happen to have some sample project that I could try? I'm sure you have tested this many times already.

Thanks
Juho

[Håkon Alseth]

Hi,

 

This is what I did.

1. issue a recover to ensure clean state: "nrfjprog --recover -f nrf53"

2. take the samples/basic/blinky/ and configure it with board name "nrf5340_dk_nrf5340_cpuapp", and flash that.

3. Power cycle

4. Measure with an am-meter over P22. (I measure ~13-14 uA)

I kept the USB powered and connected. There's several buffers etc. that are not on the VDD_NRF net, including the GPIOs, so if you do not keep the VBUS present, it might leak into those connected nets, and your current consumption will then be higher than expected.

Could you try this and see if you measure in the uA range?

 

Kind regards,

Håkon

[jvr]

Hi

Thank you for the quick reply.

I actually have two PDKs and decided to try both, running recovery and flash for each.. Surprisingly enough, the original kit yields 1.70 mA in P22 while the other shows consumption close to zero (need to rerun the test with a better multimeter). The boards appear identical and have the same modifications made (=cut the solder bridges between P22 and P23 terminals). Switches are in the same position. Only difference I could see in the boards was in the number in bottom layer silk screen (top left corner): the PDK showing 1.70 mA has 44-19-946 while the other board has 44-19-969. Is that a serial number or batch? Could it be that the other PDK is defective?

Having USB connected didn't seem to make much of a difference. Actually your tip is a contradicting the instruction in Info Center (https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_nrf52832_dk%2FUG%2Fnrf52_DK%2Fhw_meas_current.html), although I do see your point.

Thanks
Juho

[jvr]

Hi

1.7 mA kit behaves very similarly with USB vs coin cell. There's perhaps 50 µA of difference.

It seems odd that "nRF ONLY" switch doesn't seem to make any difference either.

Maybe I'll try to isolate the nRF even some more.

I ran the recovery & download process a few times, the output was identical for each board.

1.70 mA board does take about 4 mA for a few seconds after startup before it drops to 1.70.

Working board drops to 16.5 µA or so almost instantly.

Thanks
Juho

[Håkon Alseth]

Hi Juho,

 

If you send me a direct message, with your address + phone number, I'll try to get a replacement kit sent to you.

 

Kind regards,

Håkon

[jvr]

Hi

Thanks, much appreciated. PM sent.

By the way, it's very nice that you create and make available development kits like this even if they don't have complete software support, or if they have some hardware glitches. They do provide very valuable insight to the new product even if they are not perfect (and in R&D, things rarely are anyway).

Juho

[Håkon Alseth]

Hi Juho,

 

jvr said:

By the way, it's very nice that you create and make available development kits like this even if they don't have complete software support, or if they have some hardware glitches. They do provide very valuable insight to the new product even if they are not perfect (and in R&D, things rarely are anyway).

Thank you for the feedback. This is what we're aiming for. Trying to get you acquainted with the hardware as early as possible, so that you're able to look at other aspects than just the application firmware (hardware development, basic evaluation and testing, PC software etc).

PS: The replacement kit was sent on friday, last week. Could you let me know if it does not arrive within this week?

 

Kind regards,

Håkon 

[jvr]

Hi

I just got the new PDK. Thanks!

Bad news though, the board seems to behave pretty much the same as the other 1.7 mA board. I made the same modifications and did the same recovery operation a few times before programming the blinky example. I even tried cleaning the board with IPA, no effect. This PDK is number 44-19-996 for what it's worth.

Could you build a "known good" binary and share it here (or PM)? I think it would be best to rule out software-related problems (who knows if there's some tiny difference in the source or toolchain somewhere...). I've attached my built binary and binary read from PDK after flashing.

Another thing to check would be whether the firmware on embedded j-Link is (emStudio asks to update it which I allowed for the newest PDK). Although I guess it shouldn't matter if "nRF ONLY" mode is used (it doesn't seem to make any difference).

Juho

3157.blinky.zip

blinky_flash.zip

[Håkon Alseth]

Hi,

 

I have used the ncs/zephyr/samples/basic/blinky untouched at my end. I tested your binaries, and my kit goes into low power mode.

However; I have been debugging a bit. It seems that the nRESET signal is present (set high from external logic, the segger IC), even if you disconnect the jumper from "nRF current measurement".

This will then try to reverse-power up the nRF, and I believe this is the reason why some of your kits are misbehaving. I cut SB42 (located above the "IF BOOT/RESET" switch) and got promising results after that.

 

Could you try this and see if that works better?

 

Kind regards,

Håkon

[jvr]

Hi

Thank you for the suggestion and for taking the time to debug this. Unfortunately it doesn't seem to have any effect: Current consumption is still 1.7 mA (tried with and without USB connected, in default and NRF only mode).

I think this might have something to do with the interface MCU though: Current consumption drops to about 800 uA if I keep the RESET button pressed, and there's a brief period (3-4 seconds) of about 4 mA consumption right after reset during which nRF is already running normally as indicated by the LED blinking.

Juho

[Håkon Alseth]

Hi Juho,

 

I think I recreated your scenario. I see approx. 1.1 mA, which is a bit lower than yours.

Could you try these steps and see if there's any changes in the overall current consumption?

1. Build blinky as-is, for nrf5340_dk_nrf5340_cpuapp.

2. Flash blinky for the app cpu.

3. build blinky, with main having only while(1) k_sleep(interval);, for nrf5340_dk_nrf5340_cpunet (no GPIO toggling!)

4. flash blink for the net cpu.

 

I think that the network core is running on your end. If it is empty (can be done by issuing "nrfjprog -e -f nrf53 --coprocessor CP_NETWORK", and for app: --coprocessor CP_APPLICATION), it'll still run.

 

PS: the 800 uA in reset is the same that I see if I keep holding the reset pin.

 

Kind regards,

Håkon

[jvr]

Hi

Indeed this seems to fix the issue. Thanks! Now I'm seeing 17..18 µA current for all boards.

Looks like my original hunch was correct after all. I think it would make sense to modify the example (or fork it for nRF5340) so that both cores would blink their own LED. It would make it easier to see what's going on in each core. I couldn't figure out yet if that would be possible to do.

Also it seems to be possible to check symbol CONFIG_SOC_NRF5340_CPUAPP or CONFIG_SOC_NRF5340_CPUNET instead of modifying the source code by hand.

Juho