• State Verified Answer
  • Locked Locked
  • Replies 11 replies
  • Subscribers 64 subscribers
  • Views 9013 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 103443
Options
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

Daniel Bayeh

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

  • 0 in reply to Daniel Bayeh

    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.

  • 0 in reply to Daniel Bayeh

    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.

  • 0 in reply to Daniel Bayeh

    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.

  • 0 in reply to Daniel Bayeh

    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.

  • 0 in reply to Daniel Bayeh

    Torbjørn - the chip info is as follows

    QFAAG0 1403A0

    What is the revision after which the power registers don't need to be cleared?

Related