nRF52832 errata and docs: __get_FPSCR() has side effects?

[charles]

We're disabling pending FPU exceptions and clearing pending FPU IRQs before calling sd_app_evt_wait(), as per a few references:

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v14.0.0%2Fhardware_driver_fpu.html&cp=4_0_3_2_2

http://infocenter.nordicsemi.com/pdf/nRF52832_Rev_1_Errata_v1.6.pdf

We see the same pattern recommended, which is an unused call to __get_FPSCR(). I understand that issuing FPU instructions triggers lazy stacking, but the examples provided already retrieve the FPSCR register contents using __get_FPSCR().

I thought there might be side effects to reading FPSCR, but the ARM manual doesn't mention any:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/BABBFJEC.html

So, does anyone know the purpose of the additional "(void)__get_FPSCR();" after __set_FPSCR(...) is called?

[ketil]

Hi,

I am looking into this. Might not be able to provide an answer until next week.

Ketil

[ketil]

Hi again,

Sorry for the delayed response.

The reason the register is read immediately after writing is because of a generic method for bus-synchronization. It is strictly speaking not necessary in this architecture. However, it should not have any impact on performance.

Ketil

[charles]

Thanks, Ketil.

Could I ask you to consider updating the errata and documentation and deleting this unnecessary line? /Especially/ in errata, I assume that every line of code is required for the CPU that the data sheet refers to. If the nRF52832 doesn't need to call this function, it probably shouldn't be present as a mitigation.

I lost an hour to searching the internet and reading various Nordic and ARM reference manuals trying to understand why this was necessary; it made me concerned that I was missing critically-important calls to __get_FPSCR() in our application's FPU code.