pwr_mgmt_fpu_sleep_prepare fails with assert

[Allen]

Hello,

We have an application with a S132 device, SDK 14 and Softdevice v5.0.0. On some devices, an assert is being thrown in the sleep prepare function. This is the line ASSERT((fpscr & 0x07) == 0);

What could the possible cause of this be? Is there any special PCB support required for this to work? The devices that work have a different PCB revision. Is there chip errata pertaining to this?

Thanks

[Allen]

It appears this isn't an issue after all. The sample application works on boards that previously failed. Reverted to an older version of our firmware and that works as well.

On a side note, the ASSERT indicates that the exception condition existed, not that it was unable to clear the exceptions in the register. Removing the ASSERT condition enables the failed boards to function normally.

The mystery is why 1 board works.

[Hung Bui]

Still, you haven't revealed that if you use FPU or not.

[Allen]

Yes, we recently added code that used the FPU. Is there a way to enable FPU exception handling? This way we should be able to identify the offending code from the call stack.

[Hung Bui]

If you have a look at pwr_mgmt_fpu_sleep_prepare() function, you can see we try to clear FPSCR with : __set_FPSCR(fpscr & ~0x9Fu);

So we assert if the bit can't be cleared.

Do you have that assert all the time ? Have you check what kind of FPU activity can cause that assert ?

[Allen]

That is what I thought the code was doing originally and the reason I got so worried. Actually the code is asserting based on the condition existing before it was cleared. The FPSCR is not read again as a verification that the bits got cleared.

[Hung Bui]

Ah hah, now I got it, it seems more like a bug to me now :) I will check with R&D and confirm this back.