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

  • 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.

Reply
  • 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.

Children
No Data
Related