nRF52 FP exception conundrum

RE: nRF52 FP exception conundrum

Jørgen Holmefjord — Fri, 16 Jun 2017 12:27:01 GMT

The FPU in Cortex M4 does not support double precision floating point, so these will be handled in software. I don't see any reason why this should affect the single precision operations supported by the hardware. It is hard to give any advice on this without having any specific example to work with. If you could manage to create an example that reproduce this issue, it would be easier to help you.

RE: nRF52 FP exception conundrum

Ray — Thu, 15 Jun 2017 16:14:11 GMT

Thank you. I am trying. At this moment my challenge is that there is no repro, and it is occurring intermittently in the field.

By code inspection and reconfiguration I have determined that it is somehow related to some 64-bit (double) operations that are occurring just prior to the 32-bit (float) operations that are trapping.

Without the double operations, there is no crash. With the double operations having been performed, the subsequent (and completely unrelated) float operations take a trap.

RE: nRF52 FP exception conundrum

Daniel Wang — Thu, 15 Jun 2017 16:07:50 GMT

Maybe you could post some example code so the problem can be reproduced?

RE: nRF52 FP exception conundrum

Ray — Thu, 15 Jun 2017 16:05:44 GMT

Apparently no community thoughts in this area. Any official thoughts?

Alternatively, is there a way to completely disable FP traps, as a brute force workaround?