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

ON mode IDLE power >2mA

2mA in ON mode (IDLE) far too much. One timer should running to wake the device up after one minute, to take a measurement before going to sleep.

nRF51422_PS_v2.1

  • 2.6 μA at 3 V ON mode, all blocks IDLE

How do I see what peripherals are ENABLED? I am using the twi_sw_master. But I am not using the adc, or gpiote.

I have set the following to no effect. "just incase it was initized, Is there a function to read enabled peripherals?

NRF_UART0 ->ENABLE = UART_ENABLE_ENABLE_Disabled << UART_ENABLE_ENABLE_POS
NRF_TWI1->ENABLE = TWI_ENABLE_ENABLE_Disabled << TWI_ENABLE_ENABLE_POS

The device is not advertising. If the radios are still on, how to I force it off? The jtag is disconnected and SWDCLK is pulled low by a 12k resister.

main loop

while(1)
{
     app_sched_execute();
     power_manage();
}

The state machine is event driven from timers and on_ble_evts

I suspect something is keeping the nrf51422, nrf51822 from going idle

I am looking for a good suggestion to determine what it is, so that I may disable it and allow the nrf51422 to go idle.

I should note, direct debugging through keil is not possible because, devzone.nordicsemi.com/.../ Firmware includes nrf51422, rf51822, s110, bootloader and application. I could add a pin sense to the bootloader to create a state where the bootloader will not proceed until the pin is released. This would keep the nrf51422 from starting ble radio during loading. Is this what should be done? Is keil with jlink debugging the way to find what is keeping the nrf51422 from going idle?

Parents
  • The nRF is going into sleep, but the 16M clock source is being kept alive as one of the peripherals that requires the clock is still running. You can see a complete list of the peripherals requiring the 16M clock in the chapter "8.3 Block resource requirements".

    While debugging, you can see the state of all peripherals by accessing them from the tab "Peripherals". Set a breakpoint right before going into sleep mode, and see which of the peripherals are still running, and may be causing the 0.7 mA current consumption.

    Cheers, Håkon

Reply
  • The nRF is going into sleep, but the 16M clock source is being kept alive as one of the peripherals that requires the clock is still running. You can see a complete list of the peripherals requiring the 16M clock in the chapter "8.3 Block resource requirements".

    While debugging, you can see the state of all peripherals by accessing them from the tab "Peripherals". Set a breakpoint right before going into sleep mode, and see which of the peripherals are still running, and may be causing the 0.7 mA current consumption.

    Cheers, Håkon

Children
Related