pwr_mgmt_fpu_sleep_prepare fails with assert

ajcurtis gravatar image

asked 2018-01-12 20:47:24 +0100


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?


edit retag flag offensive close delete report spam


Could you tell a little bit more about the project ? Do you use floating point unit (FPU) in your project ? Could you check what the value of fpscr is when error occurs ?

Hung Bui ( 2018-01-15 11:19:51 +0100 )editconvert to answer

This issue must be an errata with the processor. However I have not been able to find an errata regarding this so we do not know which versions of the chip has the issue. I have tested 4 different processors. 3 of the exhibited the issue. 1 processor seemed to work.

Perhaps we can solve the problem by avoiding certains serial numbers or processor lots? Any information regarding this would be appreciated.

ajc ( 2018-01-15 18:38:41 +0100 )editconvert to answer

Please provide the information that I asked above. Do you see the same issue when you test with our SDK example ? Could you read the laser marking on top of the chip with and without the issue ?

Hung Bui ( 2018-01-16 11:28:45 +0100 )editconvert to answer

We are using an ISP1507 module. Here is the information from the top of the chip. I am not sure if any of it correlates to an rf52832 part number.

Without the issue 1. ISP1507 2. AX: 1649B 3. IC:11306A-ISP1507

With the issue 1. ISP1507 2. AX: 1727B 3. IC:11306A-ISP1507

ajc ( 2018-01-16 18:02:15 +0100 )editconvert to answer

1 answer

Sort by » oldest newest most voted
ajcurtis gravatar image

answered 2018-01-16 21:01:49 +0100

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.

edit flag offensive delete publish link more


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

Hung Bui ( 2018-01-17 11:18:48 +0100 )editconvert to answer

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.

ajc ( 2018-01-17 18:06:02 +0100 )editconvert to answer

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 ?

Hung Bui ( 2018-01-18 15:09:28 +0100 )editconvert to answer

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.

ajc ( 2018-01-18 17:49:12 +0100 )editconvert to answer

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.

Hung Bui ( 2018-01-19 11:20:49 +0100 )editconvert to answer

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer. Do not ask a new question or reply to an answer here.

[hide preview]

User menu

    or sign up

Recent questions

Question Tools

1 follower


Asked: 2018-01-12 20:47:24 +0100

Seen: 23 times

Last updated: jan. 16