This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

NVIC_EnableIRQ vs sd_nvic_EnableIRQ

I have an application that uses the soft device and RTX RTOS. I am seeing a behavior I can't explain. I use sd_app_evt_wait() in the idle thread after I have turned off power to the peripherals in use and set up GPIOTE PORT event to wake it up from sleep state. I have also implemented the handler for the GPIOTE which will restore power to the peripherals. For this test, I used one of the GPIO lines to initiate sleep mode. In the on state, I have some LEDs that blink. Once in sleep state, it turns off the LEDs and remains in low power state but still handles BLE activities. I can read and write to the device using MCP while in sleep state.

The GPIOTE event /interrupt isn't used when in on state. It is configured and the interrupt enabled just before sleep mode entry. The problem I see is that sd_nvic_EnableIRQ(GPIOTE_IRQn) doesn't seem to enable the interrupt operation. I have set breakpoints in the handler and can see the GPIOTE->EVENT_PORT going active when the configured button is pressed, but the handler is never called. But when NVIC_EnableIRQ() is used instead, it functions as expected. I have two questions related to this.

  1. Why is the sd_nvic_EnableIRQ() not working?
  2. Why is the NVIC_EnableIRQ() working? I would have thought it would misbehave when this fuction is called while the soft device is enabled.

Also, once it is in low powr mode, I am seeing 910uA current when it isn't connected to a client and 1.2mA when connected. What am I missing that is causing this much current?

Regards, Daniel

Parents
  • Thank you, Torbjørn. Since I posted this question, I had found every peripheral (in nrf51) that has a POWER control register and made sure to disable those I am not using before calling sd_app_evt_wait. The only peripherals that are used by the application and remain powered are

    1. RTC1 - this is used as RTOS tick timer. This timer is running to keep track of a clock and every second, it generates an interrupt and in the exception handler, it increments a counter and goes right back to low power state.
    2. GPIOTE, LPCOMP - these are used as wake up sources

    I am leaving the following peripherals alone as they are used by the soft radio - RTC0, TIMER0, RNG, ECB, AAR, CCM.

    With this setting, I am still seeing 60uA when the device is not connected to a client and ~470uA when connected. I am using the following connection settings.

    1. Min connection interval = 250ms
    2. Max interval = 500ms
    3. Slave latency = 1
    4. Supervisor timeout = 4sec
    5. Advertising interval = 1022.5ms with no timeout

    Is 60uA to be expected with the radio on and advertising once a second with the peripherals that are still powered on? Is there something else I am missing? I am making sure the external 32KHz clock is used by initializing the soft radio as follows.

    SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_XTAL_20_PPM, true);
    

    Regards, Daniel

Reply
  • Thank you, Torbjørn. Since I posted this question, I had found every peripheral (in nrf51) that has a POWER control register and made sure to disable those I am not using before calling sd_app_evt_wait. The only peripherals that are used by the application and remain powered are

    1. RTC1 - this is used as RTOS tick timer. This timer is running to keep track of a clock and every second, it generates an interrupt and in the exception handler, it increments a counter and goes right back to low power state.
    2. GPIOTE, LPCOMP - these are used as wake up sources

    I am leaving the following peripherals alone as they are used by the soft radio - RTC0, TIMER0, RNG, ECB, AAR, CCM.

    With this setting, I am still seeing 60uA when the device is not connected to a client and ~470uA when connected. I am using the following connection settings.

    1. Min connection interval = 250ms
    2. Max interval = 500ms
    3. Slave latency = 1
    4. Supervisor timeout = 4sec
    5. Advertising interval = 1022.5ms with no timeout

    Is 60uA to be expected with the radio on and advertising once a second with the peripherals that are still powered on? Is there something else I am missing? I am making sure the external 32KHz clock is used by initializing the soft radio as follows.

    SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_XTAL_20_PPM, true);
    

    Regards, Daniel

Children
  • Check your current consumption in idle state. It should be around 3-4uA. Based on S110_SoftDevice_Specification_v1.3A.pdf Advertising event power profile your average current consumption with 1 second advertising interval should be around 30uA. How do you make current measurements?

  • I am not sure what you mean by measuring the current in idle state. I assumed that is what I did by calling sd_app_evt_wait(). I have used a fluke 287 hand held and Agilent 34410A benchtop DMMs. I get 60uA and 63uA.

  • Remove advertising start from your code so your device won't advertise or be connected, in this case youe device will be in sd_app_evt_wait() state that is idle and idle current should be (ION + IRTC + IX32k) = 3-4uA.

  • What revision of the nRF51822 do you have? (this is printed on top of the chip) In the later versions it should not be necessary to clear the POWER registers when entering sleep.

    I agree with Nikita it could be interesting to know the base current when the BLE stack is idle (enabled but not advertising).

    Finally, have you tried any of the standard examples in the SDK, such as the heart rate example? It would be interesting to know if you get lower current consumption numbers there.

  • I see what you mean - Nikita. I disabled advertising and measured the current and saw virtually no difference. This probably makes sense since I am advertising only once a second and the DMM isn't probably responsive enough to capture a 2-3ms duration advertising current spike. I am using our own PCBA so I can't just use the example projects. I will modify it and give it a try. It is possible this extra current is caused by something in the hardware that isn't properly initialized. Before you suspect the hardware, a colleague has the same hardware and a special test firmware where he sets it to system off and measures 6uA. I will update the heart rate project, test and update what I find out.

Related