nRF54L15: high current consumption after using FPU, need information about FPU_IRQn interrupt vector.

[Frank Viganske]

Hi,

i am working on a project using the nRF54L15.

Hardware: custom board with nRF54L15

Software:

• Wirepas SDK (1.6.2) 
• nrfx drivers (version 3.9.0) with some customization to integrate it into the SDK
• CMSIS DSP floating point libraries (Version 5.1)

I see in my current measurements that idle current increases by roughly 300µA after using the floating point unit. I already checked the developer zone for any similar tickets, and there are lots of them, though all are for other SoC, like nRF52 series. 

Most of these tickets suggest the high current consumption comes from unhandled FPU interrupts. I was already able to confirm that this is indeed the reason for the increased current. Now i'm trying to implement a solution for this.

The suggested solution from other tickets is to do something like the code below:

__STATIC_INLINE void pwr_mgmt_fpu_sleep_prepare(void)
     {
        uint32_t original_fpscr;

        CRITICAL_REGION_ENTER();
        original_fpscr = __get_FPSCR();
        /*
         * Clear FPU exceptions.
         * Without this step, the FPU interrupt is marked as pending,
         * preventing system from sleeping. Exceptions cleared:
         * - IOC - Invalid Operation cumulative exception bit.
         * - DZC - Division by Zero cumulative exception bit.
         * - OFC - Overflow cumulative exception bit.
         * - UFC - Underflow cumulative exception bit.
         * - IXC - Inexact cumulative exception bit.
         * - IDC - Input Denormal cumulative exception bit.
         */
        __set_FPSCR(original_fpscr & ~0x9Fu);
        __DMB();
        NVIC_ClearPendingIRQ(FPU_IRQn);
        CRITICAL_REGION_EXIT();

        /*
         * The last chance to indicate an error in FPU to the user 
         * as the FPSCR is now cleared
         *
         * This assert is related to previous FPU operations 
         * and not power management.
         *
         * Critical FPU exceptions signaled:
         * - IOC - Invalid Operation cumulative exception bit.
         * - DZC - Division by Zero cumulative exception bit.
         * - OFC - Overflow cumulative exception bit.
         */
        ASSERT((original_fpscr & 0x7) == 0);
     }

That is, 1. clear the FPU exception bits in FPSCR, 2. clear the pending IRQ with NVIC_ClearPendingIRQ(FPU_IRQn);

Which brings me to my problem. I can't find any definition for FPU_IRQn for the nRF54L15, neither in the Nordic Documentation nor in any of the processor header files.

For other SoCs FPU_IRQn is defined as an enum value in IRQn_Type. For the nRF54L15, in nrf54l15_application.h there is a similar type definition for IRQn_Type, but it does not contain the FPU_IRQn.

Maybe it is just named differently? 

So my question is: how do i clear the pending IRQ for the FPU on the nRF54L15?

Best regards

Frank Viganske

[Kazi Afroza Sultana]

Hello,

It seems the current draw should also have remained low if you have not enabled the FPU INTEN bits? The issue on the 52 series was that we did not have INTEN register for FPU; so the FPU IRQ signal always connected to the NVIC.

[Frank Viganske]

Hello,

no, the INTEN registers do not have anything to do with the higher current. One of the things that i checked when i found out it may be related to FPU interrupts, was if any of the INTEN bits were set, but they were all 0.

As far as i found out by now, alone the exception bits in the FPSCR are enough for the current to go up. No INTEN needs to be set.

And also it seems that the FPU itself does not have any enable bits for these exceptions, so you can't prevent the FPSCR bits from being set. Can you confirm this?

If i understood you correct, the INTEN bits in CPUC just connect or disconnect the FPU IRQ signals. They don't prevent the FPU IRQ signals from being set.

My original idea was to implement an interrupt handler for the FPU IRQs, because I was afraid that if i'd miss some FPU exceptions, it could drain my battery faster. But now I don't think this is a good idea anymore. Handling every single FPU IRQ in an IRQ Handler would slow down calculations significantly, especially with the FPUIXC exception happening very frequently.

I think it is a much better approach to just ignore the exceptions during calculation and handle them all in the end. My error handler logs all exceptions that are not of the inexact floating point type, which is irrelevant for me. Then it clears the FPSCR and the EVENT regitsters before going to sleep. It is mostly identical to the code example in my first post, except that i don't need the NVIC_ClearPendingIRQ(FPU_IRQn).

So from my point of view, this ticket is solved. I have a solution for my problem, and the interrupt handler is not needed anymore.

Best regards

Frank

[Kazi Afroza Sultana]

Hello Frank,

Thanks for letting us know that the issue is solved by ignoring the exceptions during calculation and handle them all in the end; removing this NVIC_ClearPendingIRQ(FPU_IRQn) from the code.

''As far as i found out by now, alone the exception bits in the FPSCR are enough for the current to go up. No INTEN needs to be set.

And also it seems that the FPU itself does not have any enable bits for these exceptions, so you can't prevent the FPSCR bits from being set. Can you confirm this?''

I have asked team to confirm this. I will get back to you when there is an update.

Thanks.

BR
Kazi