additional questions to nRF52832 Errata 220 clearification

[dr71]

Hi,

refering 

(1) https://devzone.nordicsemi.com/f/nordic-q-a/55197/nrf52832-errata-220-clearification

(2) https://devzone.nordicsemi.com/f/nordic-q-a/58488/nrf52832-errata-220-clearification-need-more-information

(3) https://devzone.nordicsemi.com/f/nordic-q-a/4498/difference-between-wfe-and-sd_app_evt_wait/15954#15954

there is coming up an additional question.

Sorry for closing the last thread to early. 

@Susheel in (2) you answer me that

(a) The SD never calls sd_app_evt_wait by itself. It will also not call __WFE by itself.

(b) Yes, that is correct. You just need to call __WFE in the way that is given as the workaround for this errata.

But reading (1) again I found:

(C) The softdevice will trigger this errata inside sd_app_evt_wait() which will be called by the app. Because this is where the CPU starts to execute after the wakeup.

This contradicts your answer in (a) and reading (3):

(d) The sd_app_evt_wait is basically the safe version of WFE when using the SoftDevice. Since the SoftDevice is running in a different context than your application you cannot know if it is safe to use WFE. Therefore, use the SD function.

makes me even more unsure what to do.

My app and the SDK (15.2.0) calling sd_app_evt_wait().

So now I'm in a dilemma.I should use the function sd_app_evt_wait() to be safe with the SD but on the other hand the implementation of sd_app_evt_wait() in the SD did't contains the workaround till now.

So it is again unclear for me if I should use sd_app_evt_wait() to be safe with the SD or using the workaround to get not into trouble with errata 220.

Till now we didn't observe any strange behavior in our device. So maybe it is more safe still using sd_app_evt_wait() but than I have to fully understand the conditions of errata 220 which I didn't do till now.

Thank you in advance!

Regards,

Dirk

[Susheel Nuguru]

Hi,

You just need to replace the sd_app_evt_wait()  or any __WFE in your app wit the workaround mentioned in the ERRATA. 

Even though you are not hit with this problem, it is a timing issue that could trigger it. I would recommend you to fix it instead of waiting for it to hit your devices in the long run.

[dr71]

Hi Susheel,

thank you for clarify this. This will help us to decide how we deal with this errata.

Because I closed the last thread to early I will leave it open till it is implemented and tested.

Regards,

Dirk

[Susheel Nuguru]

I understand it :) 

I am confident that it will turn out to be fine ...

[dr71]

Hi Susheel,

one point is still not 100% clear regarding interrupts.

The thing is I'm not sure if an interrupt also will publish an event if an interrupt occurs.
Example:

The uC is waiting for an interrupt (e.g. timer) than the __WFE() state is reached and with the workaround the interrupts are disabled. Did the interrupt result in triggering an event or do the ISR run later if another event happens and the interrupts are enabled at the end of the workaround?

We had in the past the situation in the startup phase where a __WFE() never returns.

Regards,

Dirk

[Susheel Nuguru]

That is the reason we enabled the SEVONPEND bit now. So with this bit set, even the interrupts are disabled with these workaround, the internal events that generate the interrupt will be able to wake the chip. But the chip will be woken in the __WFE context and not in the interrupt context.

That is the main difference. When the chip wakes up it will enable the interrupts again and the application ISR will run as usual.

Before work around: 
ENABLE_WAKEUP_SOURCE -> __WFE-> WAKEUP_SOURCE_ISR -> RERUN_FROM_ISR  to next line of __WFE

After workaround
ENABLE_WAKEUP_SOURCE -> SEVONPEND -> DISABLE_INTERRUPTS -> __WFE -> WAKEUP to next line of __WFE -> ENABLE_interrupts -> WAKEUP_SOURCE_ISR

[dr71]

Hi Susheel,

thank you for clarifying how the workaround exactly works. This helps me to get a deeper understanding.

I implement the workaround and didn't see any side-effects till now. Therefore I will close this thread.

Thank you again,

Dirk