nRF52832 power problem

[John]

Hello,

I am working on a custom PCB with a nRF52832 and I've been unable to get the ON IDLE power under 480uA. Here are the basics regarding the setup

• nRF52832 Rev 1
• SDK 12.1.0
• Soft Device 132, revision 3.0.0
• FreeRTOS port from SDK w/ a few customizations
• NOTE! We are using tickless idle in FreeRTOS -- added by edit on Mar-17-2017
• Using TWI1, UART0, GPIO with port events, and a COMP peripheral
• All 3 RTCs in use (RTC0 for Soft Device, RTC1 for FreeRTOS, and RTC2 for "alarm timers").
• 32kHz Crystal Oscillator, 20 PPM accuracy
• 32MHz Crystal Oscillator
• DCDC converter is enabled due to HW design
• Using SAADC to make a battery level measurement

Other than the use of RTC2, the DCDC converter, and the COMP peripheral this is a very similar setup to a nRF51 project we did previously and was very low power. I am suspicious that I have done something wrong setting up the clocks as my most likely cause of the extra power burn. I'll describe the basic scenario below.

What I have found is that as the system is coming up the 32kHz OSC is first turned on (using the CLOCK driver), for our BSP to drive a 1 second heartbeat "alarm". It then is enabled again as FreeRTOS is brought up to drive the OS timer system. Lastly we enable the soft device through the call to sd_softdevice_enable(); in softdevice_handler_init();. It is immediately after that call that the ON IDLE power jumps from ~50uA to ~500uA and stays that high. Even the 50uA is too high for us, but I'm focused on the bigger issue here first.

I've been through the data sheet, the errata, the nRF51 -> nRF52 migration guide, and the forum and so far have had no luck reducing or even identifying my power culprit. I've implemented the work around for PAN-89 even though we don't use EASYDMA on the TWI. I've stepped through every peripheral to make sure only the ones I want are on. I've verified that the LF and HF clocks appear to be starting and the external HF clock is being used. The device is advertising, connectable and performs all of the other operations expected of it.

My next step is to neuter our app and FreeRTOS on our board and see if just bringing up the Soft Device by itself with a simple blinky style application results in the same power burn. In the mean time I was hoping if anyone had any ideas if they could respond to this post. I'm particularly interested in why the power consumption jumps when the Soft Device is enabled.

The nRF51 documentation used to have a very nice couple of tables of peripherals, the clocks they needed and the resulting power consumption. That would be very useful for the nRF52. It is possible I've missed it.

Thanks, John

[butch]

Just some ideas... Usual problem is board is in DEBUG mode. How are you getting to sleep i.e. IDLE ON, are you calling a SD function?

[John]

Thanks for responding! We have had the same experience in programming and/or debugging a board and seeing the power go up until you power cycle or pin reset the device, and remove the debugger. I've been careful in this case to do that in my testing.

I've tried getting to IDLE ON mode in two ways. Both are implementented in the FreeRTOS suppressTicskAndSleep which is part of the FreeRTOS tickless idle functionality. The first was to call via assembly instructions like this:

do{ __WFE(); } while (0 == (NVIC->ISPR[0] | NVIC->ISPR[1]));

The second was to call sd_app_evt_wait(); after enabling interrupts.

Same result both ways unfortunately.

[butch]

FPU disabled? I think it could easily be enabled without your knowing it. Isn't there an errata on that? I'll elaborate if necessary. (But I don't have my notes with me. I have fought a similar problem without success; I reverted to an nrf51 design as an expedient. Unexpected power usage is not uncommon, be sure to search this forum.)

[John]

I'll have to look into the FPU on Monday, thanks for the suggestion. I'll check the errata over the weekend.

[butch]

Another idea. The nrf52 ARM has a write cache. To insure that a write to an IO reg takes effect, you need to read from memory (typically the same IO reg). And since the CPU clock (64Mhz) and IO bus clock (16Mhz) are different, it may take four instruction cycles before the peripheral sees the write. I am not sure that WEV flushes the write cache. So it is conceivable there is a race if you disabled a peripheral by writing to an IO reg just before sleeping, the peripheral might not be disabled before the power manager decides what clocks are necessary during sleep. Although your code to sleep is different than what I usually see (SEV; WEV; WEV) and might not suffer this race. Anyway, when power consumption is high during sleep, one should consider whether the sleep is actually effective.