ble_peripheral\ble_app_uart current is big even diabled the uart peripheral.

[Carey]

i use ble_app_uart to send data to centrol, and i don't need the UART peripheral, so diabled uart with it: NRF_UART0->ENABLE = UART_ENABLE_ENABLE_Disabled;

but the problem is the current still is big,  I  set the APP_ADV_INTERVAL = 1000  , the current is about 750uA when in advertisement,  but if i use the same APP_ADV_INTERVAL in example"experimental_ble_app_blinky" , the current could be less than 60uA in advertisement mode, it means "ble_app_uart" example consumed more about 700uA, 

So my question is : which has consume that 700uA current, how to diable it?  

[bjorn-spockeli]

Hi Carey, 

the 700uA current consumption indicates that the 16MHz RC oscillator is still running. 

Run current for 16 MHz RC oscillator: 750μA 

So could you instead of just disabling the UART peripheral comment out uart_init() in main() as well as comment out references to app_uart_put() in main.c 

Best regards 

Bjørn

[Carey]

I have not see any useful infomation about RC oscillator in uart_init() and app_uart_put(), but i have compared the differents between ble_app_blinky and ble_app_uart, the ble_app_blinky it configed in 16M crystal in all time, but ble_app_uart after configed to 16M crystal, if continue to run, sometims it can changed back  to 16M RC , it's very strangely ,  why sometimes it changed back to 16M RC, sometimes would not change until reset?

[bjorn-spockeli]

Did you comment out the code that I pointed out in my previous comment? In the application you can set the Low Frequency Clock Source, i.e. either the external 32kHz crystal or the internal 32kHz RC oscillator. The nRF51 will then exclusively use the configured clock source when ever a 32kHz clock is needed.

For the 16MHz clocks its a bit different. The nRF51 will automatically switch to the 16MHz XOSC  when the Radio is used and back the internal 16MHz RC when the Radio event is over. This means that if the radio is not active and the CPU or a peripheral requiring a 16MHz clock, then the 16MHz RC will be running. 

You must make sure that all peripherals that require a 16MHz clock is disabled before entering sleep mode. Otherwise the peripheral and the clock will still be active even though the CPU is sleeping. 

[Carey]

Hi, thanks , at last i have found the reason,it's just because i have used the GPIOTE, if i comment out the "gpiote_init();", the current is less than 60uA,  but i need to interrupt from external GPIO input. How to acheve it and also can make sure low power consumption?

[bjorn-spockeli]

Happy to hear that you found the culprit. 

The GPIOTE peripheral can either use the IN event or the PORT event to trigger an interrupt. The IN event requires the HFCLK to be running, even when you go to sleep. The Port event on the other hand does not require the HFCLK to be running, but the GPIOTE PORT event can only detect one pin at the time. If you have several pins triggering the PORT event, the event will only trigger once. This due to a DETECT signal in the GPIOTE core which is muxed with all the GPIOs configured with wakeup.

If you only need to detect one external GPIO asserting at the time then you can simply change .hi_accuracy from true to false innrf_drv_gpiote_in_config_t struct passed to the nrf_drv_gpiote_in_init() call that initializes the input pin.

If you need to detect multiple pins asserting at the same time then I recommend that you use the fw-library app_gpiote. This library allows the user to have multiple wake-up sources, because the library inverts the wakeup polarity on the specific pin.