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,

It's correct that SDK 17.1.0 does not implement the errata 220 workaround. 

Remo said:

If we implement the loop ourselves, what does our application need to do when a SoftDevice-specific event occurred (e.g. RADIO)? Do we have to clear any pending IRQs/events, or can we simply go to sleep again?

The IRQ pending bit will be cleared as soon as the Softdevice has serviced the ISR, the same applies to application interrupts. I quickly tested this here by replacing the sd_app_evt_wait() call in nrf_pwr_mgmt_run() with this app_evt_wait() function I implemented:

/*
 * Enter system ON idle mode and return only when application level interrupts are triggered.
 * This function requires SEVONPEND to be enabled in the application.
 * (SCB->SCR |= SCB_SCR_SEVONPEND_Msk;)
 */
static void app_evt_wait(void)
{
    uint32_t pending_irqs0;
    uint32_t pending_irqs1;

    do
    {
        __disable_irq();
        MWU_DISABLE();
        __WFE();
        __NOP();__NOP();__NOP();__NOP();
        pending_irqs0 = NVIC->ISPR[0];
        pending_irqs1 = NVIC->ISPR[1];
        __enable_irq();
        /* Note: mwu is enabled internally in the Softdevice during
         * forwarding of application interrutps
         */
        MWU_ENABLE();
    } while ((pending_irqs0 & __NRF_NVIC_APP_IRQS_0) == 0ul &&
             (pending_irqs1 & __NRF_NVIC_APP_IRQS_1) == 0ul);

}

Disclaimer: This function has not been thoroughly tested or reviewed by others.

Remo said:

easy because we have multiple wakeup-sources (rising edge on GPIO was only one example).

Do you use the wait for event function in a superloop in main?

Best regards,

Vidar

[Remo]

Hi Vidar

Thank you very much for this function. We will test it on our side.

Yes, we are using this function in a super loop in main.

Best regards

Remo

[Remo]

Hi Vidar

I tested your function, and it seemed to worked with one exception: the function is not left when the SD_EVT_IRQn occurs. I mean the SD_EVT_IRQHandler is called, but the function app_evt_wait() is not left (assumingly because the SD_EVT_IRQn is automatically cleared). Do you have an idea how to solve this? How is this handled in sd_app_evt_wait()?

Best regards

Remo

[Vidar Berg]

Hi Remo,

Detecting the SD_EVT_IRQn is more tricky as it is a SW interrupt that is set pending within the Softdevice ISRs to notify the app of a SD event. I suggest adding a volatile flag in the app to cover this.

Best regards,

Vidar

[Remo]

Hi Vidar

Ok, solving this with a flag worked.

Thanks again for all the help. It was very appreciated.

Best regards

Remo