Workaround for erratum [220] when using FPU

[Remo]

Hi

We are using the nRF52832 with the SoftDevice S132 V7.2.0.
Recently, we had to enable the FPU whereby we have to re-evaluate the consequences of erratum 220.

According to this description, the SoftDevice V8.x should be used when the FPU is enabled.

But according to this thread, it seems that there would be also a workaround for SoftDevice V7.2.0 when the FPU is enabled by disabling stacking of FPU registers.

Is that correct? Could you please specify how this workaround can be implemented?

Many thanks in advance.

Best regards

Remo

[Vidar Berg]

Hello Remo,

It is possible to implement the workaround in the application code, please see this thread:  RE: Random bad instruction faults at 0x16274 with softdevice s132 version 7.0.1. SDK 16.0.0 . Have you experienced the errata in your current application?  

Best regards,

Vidar

[Remo]

Hi Vidar

Thank you very much for the really fast answer! ;-)

No, we have not yet experienced this erratum. We just went through the errata-sheet and wanted to ensure that we will not run into this issue in the future.

Have I understood this correctly, that it is sufficient to disable the FPU context saving procedure by setting ASPEN=0 before calling sd_app_evt_wait()?

Best regards

Remo

[Vidar Berg]

Hi Remo,

Looking at this now, I think I would be more comfortable with option 1 and calling __WFE() from the app to avoid introducing potential new issues. As mentioned in my earlier response, the compiler may use floating point registers as general purpose registers. I'm not sure how common this is, but it might be more likely to happen than the errata.

Best regards,

Vidar

[Remo]

Hi Vidar

Thank you. You are right, option 1 sounds more reliable.

You've written that with option 1, we will also be woken up in case of SoftDevice interrupts (RADIO, TIMER0, RTC0, ...). Do you have a proposal how this function shall look like so that it behaves as sd_app_evt_wait()? Or would it be possible that you can share the code of sd_app_evt_wait() how it is implemented in SoftDevice V8.x.

Best regards

Remo

[Vidar Berg]

Hi Remo,

The implementation of sd_app_evt_wait() in the SoftDevice is more complex and differs from how it you would do it in an application. This is because it involves an SVCall and defering of the __WFE() call from the interrupt context.

Remo said:

You've written that with option 1, we will also be woken up in case of SoftDevice interrupts (RADIO, TIMER0, RTC0, ...).

Are you using a supperloop, or are there other reasons for why this is problematic in your application?

Best regards,

Vidar

EDIT: forgot to add that nrf_pwr_mgmt_run() also handles clearing of FPU events with PWR_MGMT_FPU_SLEEP_PREPARE(). 

[Remo]

Hi Vidar

Our application is controlled by commands from the UART interface, e.g. to "sleep" in system ON mode until a rising edge on a certain GPIO occurs. We relied on the behavior that the function sd_app_evt_wait() only returned when an application-based event occurred. Therefore, it would be great to have a workaround that behaves the same way as sd_app_evt_wait() did.

When I've understood the code in PWR_MGMT_FPU_SLEEP_PREPARE correctly, this is the workaround for erratum 87 and not 220. Or does this also fix erratum 220?

Best regards

Remo