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
Hello Jørgen,
Yes, NUM_ADC_CHANNELS is defined as 2.
This is custom hardware. Besides the 52832 module, then is a NAND, ECG ADC, Accelerometer and LM70 temperature sensor. The DCDC regulator feature is enabled. I could provide a schematic if necessary.
I would be happy to share the project. However without the hardware it probably will not be of much use. 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. Is the SAADC the only peripheral that would require HFCLK? We are using SPI and I2C as well.
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. (all the graphs above are debugger starts) Can you think of anything in the start sequence would be different when debug mode is enabled?
Allen said:I would be happy to share the project. However without the hardware it probably will not be of much use.
Are you not able to reproduce the increased current consumption on a nRF52 DK?
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).
Allen said:Is the SAADC the only peripheral that would require HFCLK?
Many peripherals requires HFCLK, including SAADC, TIMERs, RADIO, UART, SPI, TWI, I2S, PWM, etc. The difference between the SAADC and most other peripherals is that it will have high current consumption once it is started, not just when transmitting/operating. Peripherals like SPI and TWI starts a transfer that will finish quite quickly, which will give high current consumption during the transfer, but not when transfer is done. Other peripherals with high current consumption over a long period of time is UART started in RX mode, which requires the HFCLK (and EasyDMA if UARTE is used) to be running, as you do not know when data is incoming. Similar for the SAADC, you do not know when the sample task will be triggered through PPI, so you need to be ready at all times.
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.
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.
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.
Adding a note here for future users because I had the same issue and the posted solutions didn't work, due to a slightly different config.
I have a very low sample rate application, which is using SDK 17.1 and NRFX_SAADC_API_V2 because I wanted a simple non-blocking mode. Only capturing one channel at a time. And oversampling, though that isn't relevant to the problem.
Sequence looks like this:
SDK_ASSERT(nrfx_saadc_simple_mode_set((1u << (unsigned) channel), NRF_SAADC_RESOLUTION_14BIT, NRF_SAADC_OVERSAMPLE_256X , NULL)); nrf_saadc_value_t value = (int16_t) 0x8000; // Invalid ADC value SDK_ASSERT(nrfx_saadc_buffer_set(&value, 1)); SDK_ASSERT(nrfx_saadc_mode_trigger());
Before that call, idle current is ~5uA. After it, it's almost 500uA.
As stated in other answers (but not explicitly), the SAADC appears to require a STOP event to allow its EasyDMA to go back to low-power. The proposed solutions say to call nrfx_saadc_uninit(). But in the NRFX_SAADC_API_V2 API:
void nrfx_saadc_uninit(void)
{
nrfx_saadc_abort();
NRFX_IRQ_DISABLE(SAADC_IRQn);
nrf_saadc_disable();
m_cb.saadc_state = NRF_SAADC_STATE_UNINITIALIZED;
}
void nrfx_saadc_abort(void)
{
NRFX_ASSERT(m_cb.saadc_state != NRF_SAADC_STATE_UNINITIALIZED);
if (!m_cb.event_handler)
{
m_cb.p_buffer_primary = NULL;
m_cb.p_buffer_secondary = NULL;
m_cb.samples_converted = 0;
}
else
{
nrf_saadc_task_trigger(NRF_SAADC_TASK_STOP);
if (m_cb.saadc_state == NRF_SAADC_STATE_CALIBRATION)
{
// STOPPED event does not appear when the calibration is ongoing
m_cb.saadc_state = NRF_SAADC_STATE_IDLE;
}
}
}
So the STOP event gets generated only if there's an event handler. In blocking mode there is not.
The solution is simple enough, just issue the STOP command before uninit:
nrf_saadc_task_trigger(NRF_SAADC_TASK_STOP);
while (!nrf_saadc_event_check(NRF_SAADC_EVENT_STOPPED))
{
}
nrf_saadc_event_clear(NRF_SAADC_EVENT_STOPPED);
Remi.G Thank you very much for updating the post. We tested your fix today and it worked perfectly!