High current consumption after updating to SDK 2.6.1

We're using a nRF5340 module on our board, and have basically everything working as we'd like using SDK 2.1.0.

I've tried updating to SDK 2.6.1, and managed to resolve all the differences with the API calls, but have found current consumption is much higher. Using 2.1.0 it's about 450 uA in normal operation, compared to 1000 or so uA using 2.6.1.

I've checked the most likely suspects - CONFIG_SERIAL is off, and the ADC is set to disabled in out overlay file. I also found this question  Power Management nrf5340 and so I've tried adding  CONFIG_PM_DEVICE_RUNTIME to the config file. It doesn't seem to make any difference. Turning CONFIG_PM off in sdk 2.1.0 didn't increase the current either.

Previously we had a problem with an older revision of this board having high power consumption in High Voltage Mode ( nRF5340 SAADC power consumption and  High Voltage Mode has high current consumption on custom nRF5340 board ) but so far as I can tell this isn't the issue here, unless there's some way to specify high/normal voltage mode in the config file?

We're running the radio connection, sampling via an ADC with NRFX_DPPI, communicating with peripherals via NRFX_SPIM, using GPIO (including interrupts) via NRFX_GPIOTE and running some timers.

I've not gone in detail through turning these all off individually, but if I prevent the adc sampling and data processing code from running, then just the radio is about 70 uA on SDK 2.1.0 and about 300 on 2.6.0. That means there's still a current difference without our gpio code running, which makes me think that's not the problem.

All of this implies to me there's not one single peripheral causing the current draw, but something about the way the chip is powered or possibly the level of sleep it goes into has changed since SDK 2.1.0. It also doesn't seem to be a flat increase to the current, but is in some way proportional to the load on the chip or something.

Can you suggest anything else to look into? Is there something I need to do to disable High Power Mode in the configuration? Or do I now need to specify the sleep mode somehow?

Parents
  • Hello,

    All the currents you list here is considerably higher than the idle current of 3-4uA I would expect.

    I think it's difficult to know exactly which is the problematic configuration here, but to just rule out any external components first, then I would have simply tried compling for instance the hello world with SERIAL=n to check if that yield the low power current.

    You can try to connect a debugger and simply go over the peripherals, and for instance check which are enabled if that may give a clue. E.g. there are two UARTs, so maybe check both are disabled.

    I don't know if you have mcuboot or not, but in theory here it could be 4 images (e.g. appcore and netcore, with each their own mcuboot), so it could in theory be any of them in worst case. So maybe build the application without mcuboot can also be something to try to narrow it down.

    The zephyr.dts file for each image in the build folder may also give some pointers.

    Another thing to test would be to go to the board file, and set SERIAL to n there, that should apply to all images, then you only needed to set SERIAL = y explicit when building for a specifif image.

    Kenneth

Reply
  • Hello,

    All the currents you list here is considerably higher than the idle current of 3-4uA I would expect.

    I think it's difficult to know exactly which is the problematic configuration here, but to just rule out any external components first, then I would have simply tried compling for instance the hello world with SERIAL=n to check if that yield the low power current.

    You can try to connect a debugger and simply go over the peripherals, and for instance check which are enabled if that may give a clue. E.g. there are two UARTs, so maybe check both are disabled.

    I don't know if you have mcuboot or not, but in theory here it could be 4 images (e.g. appcore and netcore, with each their own mcuboot), so it could in theory be any of them in worst case. So maybe build the application without mcuboot can also be something to try to narrow it down.

    The zephyr.dts file for each image in the build folder may also give some pointers.

    Another thing to test would be to go to the board file, and set SERIAL to n there, that should apply to all images, then you only needed to set SERIAL = y explicit when building for a specifif image.

    Kenneth

Children
No Data
Related