FPU divide by 0 and High Current Consumption

RE: FPU divide by 0 and High Current Consumption

Jason — Fri, 18 Nov 2016 16:42:59 GMT

Good question for low power application

RE: FPU divide by 0 and High Current Consumption

Susheel Nuguru — Mon, 05 Sep 2016 11:06:58 GMT

solution to this is to clear pending FPU interrupt

RE: FPU divide by 0 and High Current Consumption

Susheel Nuguru — Fri, 02 Sep 2016 12:07:54 GMT

OK, I spent some time in it. This is a bug for implementation of sd_app_evt_wait, it polls for the pending bit in NVIC to see if has to sleep or not and I think it has also check for the interrupt being enabled or not. I will create a ticket and track this thing.

RE: FPU divide by 0 and High Current Consumption

Susheel Nuguru — Fri, 02 Sep 2016 10:57:20 GMT

i am not sure if i understood it correctly, but yousay that sd_app_evt_wait is behaving differently on an unhandled FPU exception.

RE: FPU divide by 0 and High Current Consumption

Ole Bauck — Thu, 31 Mar 2016 11:15:08 GMT

Answer is edited to be more inline with the release notes of SDK. It seemed like only the interrupt solution works with FreeRTOS, could you confirm this?

RE: FPU divide by 0 and High Current Consumption

Susheel Nuguru — Mon, 14 Mar 2016 12:46:29 GMT

seems like FPU Automatic state preservation bit needs to be set. Can you guys try to enable ASPEN b it when you enable FPU and see if the context is stored and restored correctly?

FPU->FPCCR  |= (FPU_FPCCR_ASPEN_Msk);

RE: FPU divide by 0 and High Current Consumption

RK — Fri, 11 Mar 2016 08:28:05 GMT

Ok - that sounds more likely than a hardfault on write. The only thing which comes to mind there is as issue with stacking, or lazy stacking, of the FPU registers when the SVC call is executed or later in the Softdevice handling of them. I suppose that writing the FPCSR register will set the CONTROL.FPCA bit which means the next SVC call (or any interrupt) will stack (or lazy stack) the FP registers.

That said I can't reproduce this, not in a trivial example anyway, I called an sd_ function inside the loop and it was fine, no hardfault.

RE: FPU divide by 0 and High Current Consumption

Michael Dierks — Fri, 11 Mar 2016 07:36:28 GMT

Above I commented on the FPSCR clearing, I stepped thru the register manipulation, that was OK. The hardfault occurs for me when I execute a soft device SVC call. I thought it might be a response to the sd_app_evt_wait, but I replaced that with some others, checking status of event set flags, and it always occured at the SVC call following the FPSCR manipulation. We have gotten the sleep pattern we expect, but there are some loose ends on this cleanup.

RE: FPU divide by 0 and High Current Consumption

RK — Fri, 11 Mar 2016 07:03:14 GMT

Really? The only thing I thought caused a hardfault writing to the FPU unit was if it wasn't enabled, but if it's not enabled then you wouldn't be getting FPU exceptions set. You could check at the point you're doing the write that it's not been disabled by something. You can check the SCB->CPACR register and make sure bits 20, 21, 22 and 23 are set when you're doing the write.

Sure that's where the hardfault is happening, at the write to the FPSCR?

RE: FPU divide by 0 and High Current Consumption

WestCoastDaz — Fri, 11 Mar 2016 06:47:46 GMT

RK,

Haha..I plan on not dividing by zero in the production release! Ole's answer isn't 100% correct since the writes to the FPU status register he suggests causes a hardfault.

RE: FPU divide by 0 and High Current Consumption

RK — Fri, 11 Mar 2016 06:42:34 GMT

why don't you just enable the FPU interrupt and clear the divide by zero condition when it fires.

.. or stop dividing things by zero

RE: FPU divide by 0 and High Current Consumption

WestCoastDaz — Fri, 11 Mar 2016 06:37:06 GMT

Ole,

Can you show how to apply you code with Tickless sleep? Right now the only way I can get the power down is to use a combination of tickless sleep and the idle task which is clearing the FPU interrupt.

RE: FPU divide by 0 and High Current Consumption

RK — Thu, 10 Mar 2016 01:31:28 GMT

You made me actually test it! It appears to be an effect of sd_app_evt_wait(). It's quite hard to get it to do it all just using __wfe() directly if the FPU exception is disabled (which it is). You need SEVONPEND set to make the exception raise cause an event, else the pending exception is ignored, then you need to arrange for the exception to re-trigger in order to cause another event, just ignoring it entirely and leaving it pending doesn't raise another event and __wfe() doesn't return again. So for instance clearing the exception but leaving the FPU flags will re-raise it and then you'll get another event, but that's what it takes.

Replacing __wfe() with sd_app_event_wait() makes the code busy loop constantly if the FPU exception is pending, even with SEVONPEND cleared and even if it were only raised the one time. sd_app_evt_wait() is clearly more conservative than __wfe().

RE: FPU divide by 0 and High Current Consumption

RK — Wed, 09 Mar 2016 23:25:03 GMT

And what if you don't use sd_app_evt_wait() but just __wfe(), since you're testing it it would be handy to know if the pending, disabled interrupt does keep the processor from sleeping at all, ie WFE continues to return instantly, in which case I get to read the manual again to work out why, or it's something that sd_app_evt_wait() does. I stopped using the latter a while ago because I never quite got comfortable that I knew exactly what it did.

RE: FPU divide by 0 and High Current Consumption

Michael Dierks — Wed, 09 Mar 2016 18:00:10 GMT

Learning is good.

Learning now is understanding the link between WFE on events, and how pending levels in the NVIC relate to events that cause wakeup. I clearly see the condition occur, the FPU flag is set, and the exception condition in the NVIC is raised (NVIC_IPR1, bit 6) and never cleared. When I run the code without clearing, the sd_app_evt_wait() call never stalls, returns immediately. As Darren said, if I comment out the math instruction, the NVIC pending is not set, and then the instrumented idle wait performs a very nice 1ms sleep wait, as I expect.

When I leave the math instruction, and add the code that Ole suggested, I have partial success. The sd_nvic_ClearPendingIRQ() works, and I get expected results. If I leave the __set_FPSCR() and __DMB(); __DSB(); _ISB(); calls in, then ANY subsequent sd function calls hardfault.

Still some testing to finish.

RE: FPU divide by 0 and High Current Consumption

RK — Wed, 09 Mar 2016 17:05:11 GMT

or I could just be wrong in my understanding of how disabled interrupts wake up the CPU. I thought they basically didn't, and if they did it was only once, only in WFE and only in certain circumstances. But I've been wrong before and usually end up learning something.

RE: FPU divide by 0 and High Current Consumption

Michael Dierks — Wed, 09 Mar 2016 16:36:57 GMT

So is the SD not entering the sleep state when it "sees" the event condition? This seems like another posting that RK had commented on, where the source of the sleep-exit-trigger was not apparent

wakeup-immediately-from-sd_app_evt_wait-with-external-lfclk

RE: FPU divide by 0 and High Current Consumption

RK — Wed, 09 Mar 2016 15:17:19 GMT

Hmm that's confusing. If the interrupt is disabled then it shouldn't wake the processor from WFI, nor WFE, unless SEVONPEND is also set in which case even if disabled it should trigger WFE to wake, but only once, not continuously. Don't see why it continues to wake the processor.

RE: FPU divide by 0 and High Current Consumption

Ole Bauck — Wed, 09 Mar 2016 14:58:37 GMT

EDIT 2016-03-31: To be more inline with the release notes of the SDK the example code has been changed slightly. The two solutions are also presented equally, although it seems that only the interrupt solution works with FreeRTOS.

EDIT 2016-03-11: Added explanation of why sd_app_evt_wait() does not allow the chip to sleep if pending FPU interrupt is not cleared. Solution with FPU interrupt implementation added as best solution. Previous solution kept as reference.

The FPU will generate an exception when dividing by 0 due to overflow/underflow. This exception will trigger the FPU interrupt, see here. If the interrupt is not cleared/handled the CPU will not be able to go to sleep.

The CPU will not be able to go to sleep if you are using sd_app_evt_wait(). It will return if there are any pending interrupts, even if the interrupts are not enabled through NVIC_EnableIRQ(..). You could use __WFE() instead, but then the application will wake up a lot more from events that are only handled by the SoftDevice. With SoftDevice S132 v2.0.0 sd_app_evt_wait() will also turn off MWU before calling WFE(), so using __WFE() from the application instead will lead to an increase in sleep power consumption of about 800uA.

One way to fix this is to implement the FPU_IRQHandler. First make sure to have the latest Device Family Pack (8.5.0 at the time) such that the IRQ is included in the vector table. Set priority and enable IRQ in main:

NVIC_SetPriority(FPU_IRQn, APP_IRQ_PRIORITY_LOW);
NVIC_EnableIRQ(FPU_IRQn);

Implement the FPU_IRQHandler and clear the FPSCR. The FPSCR state is pushed on the stack when we enter the interrupt and popped when we exit the the interrupt. Therefore we cannot use __set_FPSCR() since the value will be overwritten when we exit the interrupt. We have to change the stack value instead:

#define FPU_EXCEPTION_MASK 0x0000009F

void FPU_IRQHandler(void)
{
    uint32_t *fpscr = (uint32_t *)(FPU->FPCAR+0x40);
    (void)__get_FPSCR();

    *fpscr = *fpscr & ~(FPU_EXCEPTION_MASK);
}

The other solution is to clear the interrupt every time the CPU wakes up from sleep. For example change the power_manage() function to:

#define FPU_EXCEPTION_MASK 0x0000009F

static void power_manage(void)
{
    __set_FPSCR(__get_FPSCR()  & ~(FPU_EXCEPTION_MASK));      
    (void) __get_FPSCR();
    NVIC_ClearPendingIRQ(FPU_IRQn);
    
    uint32_t err_code = sd_app_evt_wait();
    APP_ERROR_CHECK(err_code);
}

RE: FPU divide by 0 and High Current Consumption

RK — Wed, 09 Mar 2016 12:28:09 GMT

By default an FPU divide by zero doesn't do anything, you can set flags in the System Control Block to make it execute a Usage fault (which escalates to a hardfault if you don't have a handler); in this way it's much like the unaligned access on the M3/M4, it only faults if you ask it to.

I see nothing in the startup file which enables those flags, so it most likely just sets the divide by zero flag in the FPU (which is sticky) and returns zero.