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

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

Susheel Nuguru — Mon, 16 Mar 2020 16:57:16 GMT

Your welcome, marking this thread as closed with verified answer. If you do not agree, then please reopen this case.

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

Justin — Mon, 16 Mar 2020 16:07:02 GMT

Thanks Susheel.

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

Susheel Nuguru — Mon, 16 Mar 2020 14:58:19 GMT

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.

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

Justin — Fri, 13 Mar 2020 17:05:56 GMT

Thanks Susheel for the information.

[quote userid="6207" url="~/f/nordic-q-a/58988/errata-220-cpu-ram-is-not-ready-when-written/239729"]sd_app_evt_wait until we include the workaround to patch its implementation in the future SD versions. [/quote]

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

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

Susheel Nuguru — Fri, 13 Mar 2020 12:52:07 GMT

[quote user="johnmjustin"]Does sd_app_evt_wait() perform anything special that __WFE() doesn't? Like context saving and switching? [/quote]

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

[quote user="johnmjustin"]2. Does Softdevice code use sd_app_evt_wait() or __WFE internally? If yes how to add this workaround over there?[/quote]

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.

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

Justin — Thu, 12 Mar 2020 19:51:59 GMT

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?

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

Susheel Nuguru — Thu, 12 Mar 2020 12:17:53 GMT

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();