1.4mA in sleep on custom board

RE: 1.4mA in sleep on custom board

pbljung — Sat, 18 Feb 2017 02:00:30 GMT

We found and fixed the problem. Pin U9.25 VDD_PA is an output on the BLE module and should be floating, but the schematics and layout tie it to VDD_BAR. Board re-work to isolate that pin reduces the idle current from 1.3mA to 20uA when running ble_app_hrs.

RE: 1.4mA in sleep on custom board

Stian Røed Hafskjold — Tue, 14 Feb 2017 12:08:35 GMT

It's really hard to say what could be wrong here. If the same components consume a lot less current on a solderless breadboard than on the pcb, I guess we have to figure out what the difference is. If you want you can send us some samples so we can do measurements here. Maybe the best thing now is to open up a case in the Mypage support portal, so you can share your code, pcb layout and we can give you information on how to send samples here for further investigation. www.nordicsemi.com/.../Contact-Support-Team. Please link to this Devzone thread.

RE: 1.4mA in sleep on custom board

pbljung — Fri, 10 Feb 2017 23:06:35 GMT

Hi Stian, I ran

int main(void){
    for(;;) __WFE();
}

and still measure 1.4mA current on our rigid-flex PCB. I measure the same idle current on multiple rigid-flex boards so it is a systemic problem.

I physically cut the flex to remove other circuitry to try to identify what part of the board was pulling current but the idle current does not change. The attached schematic contains the BLE module, regulator, charger, flash memory which uses 1.4mA in idle. Other GPIO goes to the now removed circuitry.

A solderless breadboard with the same components (but no Segger) measures 11.6uA in idle. Current for individual components in idle: BLE module 3.3uA, regulator 1.6uA, charger ~0, flash 8uA.

Our app and Nordic example apps run fine on the rigid-flex board, except that idle current is very high for all apps.

RE: 1.4mA in sleep on custom board

butch — Fri, 10 Feb 2017 12:18:51 GMT

This is after POR so the radio should be in a reset configuration and state. But let me test some more, I discovered another issue that might be the cause of my symptoms. In other words, once I fix that issue, I will try to reproduce whether clearing NRF_RADIO->POWER really has any effect.

RE: 1.4mA in sleep on custom board

Stian Røed Hafskjold — Fri, 10 Feb 2017 12:00:03 GMT

Okay, seems like resetting the radio with the POWER register before you go to sleep is a good idea then. Are you able to send me any code so I can try to figure out what state the radio is in when it is draining current?

RE: 1.4mA in sleep on custom board

butch — Thu, 09 Feb 2017 15:34:48 GMT

Yes, the radio state is distinct from the NRF_RADIO->POWER register. Yes, what you say about the NRF_RADIO->POWER seems to correspond to the solar beacon example code (using that register to reset the radio configuration. And my earlier statement was wrong, that code does NOT clear the bit before sleeping, but leaves it set permanently.) Re my reported symptoms after clearing the bit early in the boot sequence on the nrf52, I did not experience the same on the nrf51. Re Vcc rise time, my app is like the solar beacon, a load switch switches power to the nrf52 at 1.9V (with a quick rise time) but thereafter Vccswitched continues to rise slowly as the nrf52 sleeps and the solar cell provides current. Before I changed the code to clear the POWER bit early, something was draining the current. I definitely need to retest, but don't have an oscilloscope.

RE: 1.4mA in sleep on custom board

Stian Røed Hafskjold — Thu, 09 Feb 2017 13:35:24 GMT

The POR state for the radio is DISABLED. If you then start the radio it is important to disable the radio before going to sleep through the TASKS_DISABLE (the SoftDevice will handle this). This is however not the same as the POWER register, although you could use the POWER register to reset the radio peripheral. Despite its name, the POWER register does not "power" up anything on the radio peripheral, it is more like an enable function, if that makes sense. But please keep me updated on what you figure out, if you find something that contradicts what I'm saying we need to investigate that further.

You say something about VCC is climbing towards 3.6V. The maximum specified rise time (t_R_VDD, Chapter 7 in nRF51822 PS) is 100ms. If the rise time is greater than this the chip will end up in an undefined state.

RE: 1.4mA in sleep on custom board

butch — Thu, 09 Feb 2017 12:30:46 GMT

It seemed to make a difference if I cleared that bit the first thing in main. My power supply is ultra low, i.e. solar and a capacitor. Before, Vcc stopped climbing at say 2V (not as designed) and after Vcc climbed towards 3.6V (as designed.) But I not certain yet. I looked in the Nordic docs for power consumption for the condition: radio is enabled and not active (RX or TX), but I could not find any spec, just something like "doesn't consume much". I also read the source for the Nordic solar beacon on GitHub, and the code does disable the radio before sleeping (but not first thing in main boot sequence.) Surely it is important for power saving to disable the radio using that register?

RE: 1.4mA in sleep on custom board

Stian Røed Hafskjold — Thu, 09 Feb 2017 11:48:07 GMT

Did you see any difference in current consumption? The POWER register set to 1 shouldn't have an impact on this.

RE: 1.4mA in sleep on custom board

butch — Wed, 08 Feb 2017 17:16:04 GMT

I just discovered that the radio is powered on after POR reset on both the 51 and 52. I always assumed most bits were reset to 0, but the docs show NRF_RADIO->POWER bit 0 resets to 1, i.e. power enabled to the radio. I haven't examined the docs re the idle current of the radio.

RE: 1.4mA in sleep on custom board

Stian Røed Hafskjold — Wed, 08 Feb 2017 11:56:31 GMT

I doubt that it is debug mode if you tie SWDCLK to ground and reset. Make sure that the chip is reset completely, i.e. that no decoupling caps keeps it on. Could you try to run just the following code to see if that changes anything?

int main(void){
    for(;;) __WFE();
}

Or even System OFF:

int main(void){
    NRF_POWER->SYSTEMOFF = 1;
    for(;;){}
}

If I understand you correctly the current consumption seems fine on the pca10028, so then I would guess that it is some issues with any of the external components on your custom board. Could you please post the schematic so we can have a look?

RE: 1.4mA in sleep on custom board

butch — Tue, 07 Feb 2017 16:40:58 GMT

I have similar issue on nrf52. Just some ideas: are you sure you sleep (you could turn on led after the sleep?) Someone might know what peripheral that current corresponds to. Have you discharged the bypass caps when unpowering to reset? Do any of the errata apply? Can you assert(peripherals off) just before you sleep? Maybe cut all traces to your external peripherals? Try another module instance? I empathize, its a hard problem to debug.