Errata: [220] CPU: RAM is not ready when written

[Justin]

Hi

Susheel Nuguru

Referring to 

https://devzone.nordicsemi.com/f/nordic-q-a/58652/additional-questions-to-nrf52832-errata-220-clearification/238659#238659

From the above post, the following statement was made:

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

For reference, the workaround for Errata 220 is the following:

SCB->SCR |= SCB_SCR_SEVONPEND_Msk;
__disable_irq();
__WFE()
__nop();__nop();__nop();__nop();
__enable_irq();

Our application is using Softdevice version < 8.0, which means it contains the Errata 220. 

Based on the statement that says to replace sd_app_evt_wait() with the workaround, how would this be done?

Would we simply remove the function call (sd_app_evt_wait) and replace it with the five lines given in errata workaround (shown above)?

Or, would we keep the function call (sd_app_evt_wait) and do the following:-  

SCB->SCR |= SCB_SCR_SEVONPEND_Msk;
__disable_irq();
sd_app_evt_wait();
__nop();__nop();__nop();__nop();
__enable_irq();


-Justin

[Susheel Nuguru]

Hi Justin,

you just replace the call sd_app_evt_wait() with the 

SCB->SCR |= SCB_SCR_SEVONPEND_Msk;
__disable_irq();
__WFE()
__nop();__nop();__nop();__nop();
__enable_irq();

[Justin]

Thank you Susheel. This help us lot.

Additional to above clarification I have following questions.

1. Does sd_app_evt_wait() perform anything special that __WFE() doesn't? Like context saving and switching? 

2. Does Softdevice code use sd_app_evt_wait() or __WFE internally? If yes how to add this workaround over there?

[Susheel Nuguru]

Justin said:

Does sd_app_evt_wait() perform anything special that __WFE() doesn't? Like context saving and switching? 

 Yes, sd_app_evt_wait has a mechanism to efficiently register and filter application specific interrupts from softdevice specific interrupts. This means that when your application sleeps using __WFE, it will wakeup for every softdevice specific activity too along with application specific activity. The application will anyways call the __WFE in a loop, but if there is a lot of BLE activity, the application wakeup due to softdevice activity will happen so frequently that the logic to execute the loop becomes significant in power.

When the application is sleeping using sd_app_evt_wait, the softdevice will never wake the application if the chip was woken due to softdevice only specific activity (internal timers, or RADIO activity dummy packets just to maintain the connection)

You can do a simple test, take any of our BLE example and replace the sd_app_evt_wait call in it with __WFE and compare the power consumption. You will find that sd_app_evt_wait is more efficient since it is designed to not wake application unless absolutely necessary.

With this workaround, you cannot use sd_app_evt_wait. The newest SD will fix the sd_app_evt_wait implementation to use the workaround internally. When we fix this, you can in the future  use sd_app_evt_wait as usual with all the benefits included

 

Justin said:

2. Does Softdevice code use sd_app_evt_wait() or __WFE internally? If yes how to add this workaround over there?

the softdevice does not sleep by itself unless the application calls a sleep function. The implementation of sd_app_evt_wait is never called by softdevice and is only called by the application. sd_app_evt_wait uses __WFE internally, that is the reason you cannot use sd_app_evt_wait until we include the workaround to patch its implementation in the future SD versions. 

[Justin]

Thanks Susheel for the information.

Susheel Nuguru said:

sd_app_evt_wait until we include the workaround to patch its implementation in the future SD versions. 

Do you have idea when will this be included in softdevice and in which version?

[Susheel Nuguru]

The fix will be included in v8.0 and planned to be released soon. We do not have the privilege to talk about the exact timelines here in devzone channels.