nrf5340 Anomaly 159 Workaround : not a workaround? Breaks QPSI Flash use on NCS 2.8.0

RE: nrf5340 Anomaly 159 Workaround : not a workaround? Breaks QPSI Flash use on NCS 2.8.0

BitWiggler2000 — Thu, 17 Jul 2025 16:28:33 GMT

This slipped by me on the first read so I wanted to give it more attention in case others come.

It's apparent that the (not publicly disclosed) reason behind anomaly 159 also existed before 2.7, but was just unnoticed. For some of use, that previous driver was working and testing OK with the CPU clock at 128mhz. To me, it seems the inclusion of this protection macro is really to protect against liability of a misbehaving silicon design.

If you want to assume this liability, NRF53_ERRATA_159_ENABLE_WORKAROUND=0 does work, but I had a hard time getting it to apply from the app or west levels. I had to remove it in the sdk source, modules/hal/nordic/nrfx/mdk/nrf53_erratas.h, by striking out the detecting logic. It must be used in some other places as well because I couldn't do it straight in the nor driver.

///* ========= Errata 159 ========= */
//#if    defined (NRF5340_XXAA) || defined (DEVELOP_IN_NRF5340)
//    #if defined(NRF_APPLICATION)
//        #define NRF53_ERRATA_159_PRESENT 1
//    #else
//        #define NRF53_ERRATA_159_PRESENT 0
//    #endif
//#else
    #define NRF53_ERRATA_159_PRESENT 0
//#endif

Hope this helps someone

RE: nrf5340 Anomaly 159 Workaround : not a workaround? Breaks QPSI Flash use on NCS 2.8.0

Sigurd Hellesvik — Thu, 06 Feb 2025 09:07:15 GMT

Right, I see your points. I will talk with the devs again

RE: nrf5340 Anomaly 159 Workaround : not a workaround? Breaks QPSI Flash use on NCS 2.8.0

BrianW — Tue, 04 Feb 2025 19:42:04 GMT

[quote userid="106736" url="~/f/nordic-q-a/117535/nrf5340-anomaly-159-workaround-not-a-workaround-breaks-qpsi-flash-use-on-ncs-2-8-0/521325"]But I want to instead ask you: Does the explanation from the dev help you fix the errors you explain in the post?[/quote]

No, I'm afraid not.

As I said, I need the fix (so don't want to 'disable' the workaround code currently in there).

However, the QSPI driver is used by multiple sub systems provided by Nordic/Zephyr (FAT-FS disk driver, NVS library, mcuboot...), so adding the CPU clock change at the application level will be a lot of work and always with a risk of missing a case (for example, I would have to modify mcuboot to change the CPU speed when it uses the secondary slot on the QSPI flash!)

Hence, I would like the QSPI driver provided in NCS to include the change to the CPU clock during accesses to protect all of the QSPI driver users. This is why I asked what the dev feel the risk is in doing this... If they wish to make it selectable with e KConfig, thats fine also.

RE: nrf5340 Anomaly 159 Workaround : not a workaround? Breaks QPSI Flash use on NCS 2.8.0

Sigurd Hellesvik — Tue, 04 Feb 2025 13:53:56 GMT

[quote user="BrianW"]

This is bit I don't understand : what exactly are the consequences of the QSPI driver modifying the CPU clock speed during the QPSI access? Given that the driver can restore it to the previous state after, so the application doesn't see any impact, it seems like there are only consequences if you DONT change the speed!

Maybe the devs can explain exactly what the risk for the application would be to incorporate the CPU clock changing code?

[/quote]

Instead of forwarding this to the devs right away:
This is opinions you have on how the driver should work right. Im not saying they are wrong, I see the logic.

But I want to instead ask you: Does the explanation from the dev help you fix the errors you explain in the post?

RE: nrf5340 Anomaly 159 Workaround : not a workaround? Breaks QPSI Flash use on NCS 2.8.0

anthony32086 — Fri, 31 Jan 2025 03:42:09 GMT

I would assume in more complex applications where the application is continuously changing hfclk for power/performance optimizations there could be a race condition between two contexts where an unaware app context would set the clock to 64mhz during a qspi transfer, after qspi_clock_div_change saves the 128div but before qspi_clock_div_restore, resulting in 128div being applied using the previously saved value.

However my application leaves 128mhz on always so this fix works for me.

RE: nrf5340 Anomaly 159 Workaround : not a workaround? Breaks QPSI Flash use on NCS 2.8.0

BrianW — Tue, 28 Jan 2025 17:25:45 GMT

Well, I understand the reasoning presented for why the QSPI driver did not alter the CPU clock.

[quote userid="106736" url="~/f/nordic-q-a/117535/nrf5340-anomaly-159-workaround-not-a-workaround-breaks-qpsi-flash-use-on-ncs-2-8-0/520409"]Perhaps the reporter is not aware that he can define NRF53_ERRATA_159_ENABLE_WORKAROUND=0 to get rid of this mechanism if he does not care about the anomaly.[/quote]

Sure, I see that, but given that the anomaly (or bug as we used to call such things) exists, and the consequences are major for the operation of the application, I don't see why I would want disable this mechanism? Rather, I want it to be fully transparent to my app!

[quote userid="106736" url="~/f/nordic-q-a/117535/nrf5340-anomaly-159-workaround-not-a-workaround-breaks-qpsi-flash-use-on-ncs-2-8-0/520409"]Such behavior of the QSPI driver would have to be requested explicitly to ensure that its user is aware of the consequences and accepts them.[/quote]

Maybe the devs can explain exactly what the risk for the application would be to incorporate the CPU clock changing code?

RE: nrf5340 Anomaly 159 Workaround : not a workaround? Breaks QPSI Flash use on NCS 2.8.0

Sigurd Hellesvik — Tue, 28 Jan 2025 15:17:17 GMT

Devs say:

"
QSPI is the only user of the 192 MHz clock, so the divider for this clock can be changed by the QSPI driver without affecting any other part of the system. But this is not the case for the CPU clock. That's why changing of its divider was not added to the QSPI driver and the application that uses the QSPI driver needs to take care of avoiding the anomaly 159 conditions, i.e. to make sure the CPU clock is switched back to the default 64 MHz when a QSPI operation is requested. I think this could be modified, i.e. the responsibility for changing appropriately the CPU clock divider could be put on the QSPI driver but not by default, so for example only when a dedicated Kconfig option is enabled. Such behavior of the QSPI driver would have to be requested explicitly to ensure that its user is aware of the consequences and accepts them.

Perhaps the reporter is not aware that he can define NRF53_ERRATA_159_ENABLE_WORKAROUND=0 to get rid of this mechanism if he does not care about the anomaly.

Does this help?

RE: nrf5340 Anomaly 159 Workaround : not a workaround? Breaks QPSI Flash use on NCS 2.8.0

bbbakke — Wed, 15 Jan 2025 20:48:58 GMT

Hello Sigurd Hellesvik,

Any update on this. I have some code that was using 2.6.2, but when I move to 2.7.0 I get the same error as reported above.

Regards

RE: nrf5340 Anomaly 159 Workaround : not a workaround? Breaks QPSI Flash use on NCS 2.8.0

Sigurd Hellesvik — Fri, 27 Dec 2024 13:07:24 GMT

Hi,

Since these are vacation times and you have a workaround for this, I will not get to this right away.

In January I will make a ticket to our devs who added this workaround to ask about this, then I will get back to you

Thanks for the thorough report!

Regards,
Sigurd Hellesvik