nRF52832 power problem

RE: nRF52832 power problem

John — Mon, 20 Mar 2017 20:54:31 GMT

Well, I finally have the board down to 18uA. It was like a plane crash: A series of issues some of which we touched on in the comments above. I picked this one to make an answer because the FPU was part of the problem. I also had a number of places where I cleared an interrupt and needed to read the register back before sleeping, and it seems to work a lot better calling the sd_app_event_wait() function in the FreeRTOS suppressTicksAndSleep function. And of course the PAN-89 work around.

Thanks both of you for the suggestions!

RE: nRF52832 power problem

butch — Mon, 20 Mar 2017 14:45:22 GMT

Re the FPU. I think there is code in nrf52_startup.c that enables it if the compiler thinks it is used. I think the compiler thinks the FPU is used if you specify certain compiler flags such as -mfpu=hard (For GCC compiler, it may be different for other compilers, and I could be wrong.) I simply commented the enabling code out and changed my compiler flags. And the current consumption of the fpu may not be a problem per se but that unhandled floating point exceptions may prevent sleep. Re GPIO, I have been wondering whether a GPIO out (even in the LOW state) during sleep consumes much current. I can't find a definitive answer in the Nordic documentation. I would guess it would not consume much power, since there would be no clocked switching (?) but I don't understand the output 'buffer' circuit. To work the problem, I added assert()'s on various IO regs for peripherals.

RE: nRF52832 power problem

John — Mon, 20 Mar 2017 12:34:10 GMT

Good suggestions @butch and @Turbo J. I have already implemented the work around for PAN-89 even though I am not using the EASYDMA. I am working on trying the FPU this morning and will work in making sure the sleep is actually sleeping. At one point during my testing I was using a GPIO keeping it low while sleeping and high after waking up and it showed that the sleep was effective. But since I'm going to be adding the FPU stuff to the same code, I'll verify again that the device is actually sleeping when I think it is.

RE: nRF52832 power problem

Turbo J — Sun, 19 Mar 2017 21:34:11 GMT

Have you checked Errata 89 in the errata sheet? See also: this answer to a similar problem.

RE: nRF52832 power problem

butch — Sun, 19 Mar 2017 16:23:59 GMT

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.

RE: nRF52832 power problem

John — Sat, 18 Mar 2017 14:51:47 GMT

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

RE: nRF52832 power problem

butch — Fri, 17 Mar 2017 20:37:08 GMT

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.)

RE: nRF52832 power problem

John — Fri, 17 Mar 2017 15:58:51 GMT

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.

RE: nRF52832 power problem

butch — Fri, 17 Mar 2017 15:30:54 GMT

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?