• State Verified Answer
  • Replies 13 replies
  • Subscribers 63 subscribers
  • Views 5340 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 123067
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

High power consumption after disconnect

Gordon

Hi,

I've just hit a strange issue with SDK 12.1 on nRF52832.

Usually on BLE_GAP_EVT_DISCONNECTED, sd_ble_gap_adv_start gets called to start advertising and everything's great.

However, if I don't call sd_ble_gap_adv_start, advertising stops (as you'd expect) but the CPU seems to get left on - drawing 3-4mA of power!

Do you have any idea what could be causing this, and how to fix it?

Some of my users want to be able to disconnect and stop the device advertising so when used in HID mode the computer doesn't keep connecting. Then when a button is pressed it'll wake and get connected to. This all works fine, however the 'low power' mode ends up drawing 3mA!

  • 0

    Q: So the DCDC converter would still draw the 3mA even if it was just kept on because of some on-chip peripheral?

    A: No, the DCDC convert itself would not draw 3mA, but if some peripheral is waking the CPU up from IDLE mode by generating interrupt constantly, this could explain the current consumption being so high.

    So, when you are testing with and without DCDC, the only difference is this line 1447 and 1448 ? If you comment out both these lines, what current consumption do you measure then?

  • 0

    Hmm - that's strange. I was doing this on an nRF52DK before (it could have been an engineering one), but now doing it on my device the behaviour is different. Normally it's 0.03mA, then I connect to the UART service via BLE (0.27mA) and send "NRF.sleep()\n" - 3.75mA. If I send "NRF.disconnect()\n" it goes through basically the same code path but enables advertising - it drops back to 0.03mA.

    If I comment out the DCDC lines, now the same thing happens (just with ~50% more power draw as you'd expect).

    However, I think I found the issue - I'll post it up as the answer.

  • 0

    Found it... I think I'd been distracted by the fact that my devkit was using an early chip, which had some erratas and was exhibiting different behaviour to the production devices.

    The actual issue seemed to be that I called ble_nus_string_send from SWI1_IRQHandler if I had data to send. While there was a check for the connection status, the global connection state variable wasn't volatile, and I think what was happening was ble_nus_string_send was getting called during the disconnect.

    Something about that and not enabling the advertising got it into a situation where it wasn't able to sleep properly.

Related