This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF5340 Tickless Idle

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

Parents
  • 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

  • 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

  • Hi Juho,

      

    jvr said:
    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?

    I do not think there's something wrong with your nRF53 device. This is a PDK, so my initial thoughts is that this might be something external to the nRF (leakage in the PDK itself for instance).

    Mine showed ~3 mA until I issued a nrfjprog --recover, which could have been the network core CPU, but I cannot state that for certain.

    Note, you should have the USB attached, even when using a coin-cell or any other external power:

    https://infocenter.nordicsemi.com/topic/ug_nrf5340_pdk/UG/nrf5340_PDK/hw_measure_current.html?cp=3_0_3_5

     

    Does the 1.7 mA kit behave equally if powered via USB vs. via coin-cell?

    In any case; I'll report these findings to the PDK hardware team, so that they can look into this. 

     

    Kind regards,

    Håkon

Reply
  • Hi Juho,

      

    jvr said:
    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?

    I do not think there's something wrong with your nRF53 device. This is a PDK, so my initial thoughts is that this might be something external to the nRF (leakage in the PDK itself for instance).

    Mine showed ~3 mA until I issued a nrfjprog --recover, which could have been the network core CPU, but I cannot state that for certain.

    Note, you should have the USB attached, even when using a coin-cell or any other external power:

    https://infocenter.nordicsemi.com/topic/ug_nrf5340_pdk/UG/nrf5340_PDK/hw_measure_current.html?cp=3_0_3_5

     

    Does the 1.7 mA kit behave equally if powered via USB vs. via coin-cell?

    In any case; I'll report these findings to the PDK hardware team, so that they can look into this. 

     

    Kind regards,

    Håkon

Children
  • 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

  • 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

  • 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

  • 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 

  • 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

Related