High power consumption after disconnect

RE: High power consumption after disconnect

Gordon — Thu, 29 Jun 2017 11:22:58 GMT

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.

RE: High power consumption after disconnect

Gordon — Thu, 29 Jun 2017 09:53:32 GMT

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.

RE: High power consumption after disconnect

Sigurd — Thu, 29 Jun 2017 08:03:46 GMT

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?

RE: High power consumption after disconnect

Gordon — Thu, 29 Jun 2017 07:10:09 GMT

So the DCDC converter would still draw the 3mA even if it was just kept on because of some on-chip peripheral? Is it a matter of checking every peripheral's registers individually, or is there one register which aggregates what peripherals are on? As I said above, it's still spending the same amount of time in sd_app_evt_wait - so presumably there won't be any difference in the NVIC registers.

RE: High power consumption after disconnect

Sigurd — Wed, 28 Jun 2017 18:08:17 GMT

The NFC errata is still valid on rev.1

Check what peripherals are active before entering sleep mode (check the peripherals registers). In order to check if a peripheral is waking the CPU up, check for pending interrupts in the NVIC register when you wake up.

RE: High power consumption after disconnect

Gordon — Wed, 28 Jun 2017 15:04:45 GMT

Ok, but I am still affected by the NFC errata for some reason? I definitely have the correct components, yes - it will works perfectly normally - it's just this one instance.

RE: High power consumption after disconnect

Sigurd — Wed, 28 Jun 2017 14:52:12 GMT

AAB0 is revision 1, so then you should not be affected by the DC/DC errata.

Are you sure that you have the DC/DC components on your board? [ L3(15 nH), L2(10 µH) and C14(1.0 µF) )? See page 23 here.

RE: High power consumption after disconnect

Gordon — Wed, 28 Jun 2017 14:28:36 GMT

Sorry, but which exact FICR register? I can't see the top because the module is in a tin can. Reading 0x10000104 (FICR) INFO.VARIANT gives 0x41414230 (AAB0) - but I'm not sure which bits are part, hardware and product. Both the old one and a newer one made just a month ago have the same number though!

RE: High power consumption after disconnect

Sigurd — Wed, 28 Jun 2017 14:18:30 GMT

There is an overview here. Packet variant and build code can be read from markings on top of the nRF52 IC.

Alternatively, it could also be found be reading the FICR register.( NRF_FICR->INFO.VARIANT )

RE: High power consumption after disconnect

Gordon — Wed, 28 Jun 2017 14:12:55 GMT

Is there an address I can check to find out exactly which one? The devices that are hit are actually using Raytac MDBT42 modules - there are ~6000 of them out there so I'd hoped they wouldn't be engineering models. Having said that they definitely require the HAL_NFC_ENGINEERING_BC_FTPAN_WORKAROUND definition for NFC, so it looks like they are either B or C.

RE: High power consumption after disconnect

Sigurd — Wed, 28 Jun 2017 14:03:59 GMT

What revision of the nRF52832 are you using? If you are using an old revision, it could be this errata that is causing the issue. (Engineering B and older)

RE: High power consumption after disconnect

Gordon — Wed, 28 Jun 2017 11:42:28 GMT

Thanks! Yes, DC/DC is enabled. It seems to stay inside sd_app_evt_wait most of the time (the same as usual) so I'm pretty sure that's not it. The code is based on a whole mix of examples, so I can't track down one in particular. If it helps, it's all online (mainly in github.com/.../bluetooth.c).

I just tested with/without DC/DC and that's the problem it seems. Without it's fine, but when turned on the power usage jumps up when disconnecting and not starting advertising right after. Is there a way around this - Short of turning it off?

RE: High power consumption after disconnect

Sigurd — Wed, 28 Jun 2017 10:53:38 GMT

Hi,

Is this with DC/DC mode enabled? What example in the SDK is your code based on ? Could be that the CPU is not entering sleep mode, or some interrupt is constantly waking the CPU up from sleep.