• State Verified Answer
  • Replies 10 replies
  • Subscribers 70 subscribers
  • Views 2215 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 269534
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

power consumption increases 1.1mA after first ADC sample

Allen

Hello,

I am experiencing a power issue after the first ADC sample is triggered. Sampling 2 ADC channels using PPI and TIMER as the triggering mechanism. Here is a capture using PPK2.

It is alright to have a spike in power but in this case, once the power increases it never decreases.

Is there a way to fix this?

TIA

Parents
  • +1

    Hi, 

    The increase in current comes from the EasyDMA being enabled and drawing current once the SAADC START task is triggered.

    In order to reduce the current, you can only have a buffer size equal to the number of active channels enabled, and not use the double-buffering feature.

    There is a low-power mode in the SAADC driver that you can try to enable, but we have previously seen some issues with this together with enabling multiple channels. If you are using LP mode, it is important that you use the function nrf_drv_saadc_sample_task_get() when setting up the PPI channels, is this will trigger the START task over PPI and not the SAMPLE task. The SAMPLE task will be triggered in the IRQ handler when the STARTED event is generated.

    The post provides another approach where the SAADC driver is uninit and re-initialized between each sampling, which should work with multiple channels.

    Best regards,
    Jørgen

Reply
  • +1

    Hi, 

    The increase in current comes from the EasyDMA being enabled and drawing current once the SAADC START task is triggered.

    In order to reduce the current, you can only have a buffer size equal to the number of active channels enabled, and not use the double-buffering feature.

    There is a low-power mode in the SAADC driver that you can try to enable, but we have previously seen some issues with this together with enabling multiple channels. If you are using LP mode, it is important that you use the function nrf_drv_saadc_sample_task_get() when setting up the PPI channels, is this will trigger the START task over PPI and not the SAMPLE task. The SAMPLE task will be triggered in the IRQ handler when the STARTED event is generated.

    The post provides another approach where the SAADC driver is uninit and re-initialized between each sampling, which should work with multiple channels.

    Best regards,
    Jørgen

Children
  • 0 in reply to Jørgen Holmefjord

    Jorgen,

    The sample rate of the ADC is very slow so I modified the code to init/sample/unit using an app_timer.

    I don't understand why EasyDMA does not seem to be a problem with other peripherals. The SPI manager uses EasyDMA and there isn't a power issue with that...?

    Thanks

  • 0 in reply to Jørgen Holmefjord

    The SPIM peripheral will consume the same amount of current when it is transferring data, but this is normally limited to a shorter period of time, as you start a transfer that finishes when all data have been transferred. The difference to the SAADC peripheral is that the SAADC is started when you configure the buffers, but the sampling/actual transfer of data to RAM happens when you trigger the SAMPLE task. Since the SAADC peripheral does not know when the sampling will happen, it is ready to transfer data to RAM at any time. Ideally, the EasyDMA access should only have been enabled after sample task has happened and result is transferred to RAM, but this is not how the design works.

    You will see similar current draw if you enable UARTE in RX mode, as this needs to be ready to transfer received data to RAM at any given time.

  • 0 in reply to Jørgen Holmefjord

    Are you not able to reproduce the increased current consumption on a nRF52 DK?

    Yes, I am able to reproduce the increased current consumption on the nRF52 DK. This is a known issue.

    Allen said:
    1.4mA at 4V is the lowest operating power I have been able to achieve. This is only possible if the SAADC is init/sample/uninit.

    I assume then that the high current is caused by the other peripherals on your board? The SAADC should be able to get down to the "few uA average" range with multiple channels (dependent on the sample rate).

    This is correct the other peripherals on the board prevent the ability to get into the uA operating range.
    However this is not the question. It appears that using the SAADC has 2 issues with increased power consumption. There is an increase of about .5mA by just initializing the peripheral. And another 1.5mA increase when EasyDMA is enabled to transfer the sample to memory. (and there is no way to get around the use of EasyDMA)
    The work around is to always init/sample/deinit when using SAADC for low power. Unfortunately our custom hardware appears to be sensitive to these power fluctuations. Trying to find another solution.
    Allen said:
    There is a secondary issue where the power profile is very noisy from power-on. However it is clean when the application is started using the debugger.

    Which PPK version are you using? If using PPK2, are you measuring in Source or Ampere meter mode? There may be some noise from the USB, but I would expect this to be the same for debug and non-debug modes.

    Yes, using PPK2 in source mode. If toggle power using the PPK the profile is noisy.

    Allen said:
    Can you think of anything  in the start sequence would be different when debug mode is enabled?

    Debug mode will enable clock source and low latency mode in order to quickly halt CPU, etc. I do not see how this could remove any noises from the power capture though.

    What do you mean by "debug mode will enable clock source". The custom hardware has a different clock source configuration than the DK. I was wondering if that could have something to do with it.

Related