• State Not Answered
  • Replies 10 replies
  • Subscribers 88 subscribers
  • Views 416 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 359813
Options

errata 166 patch not applied in SDK

Mohammed Ubaid

Hi,

Any specific reason the errata Anomaly 166 : https://docs.nordicsemi.com/bundle/errata_nRF5340_Rev1/page/ERR/nRF5340/Rev1/latest/err_340.html
resolution patch as present in nCS' "nrf53_errata.h" is not applied. in nCS SDK .?
Didn't find it being called anywhere.

Should i call it manually.?
Since symptomatically it says : Device behaves erratically on LDO.
Checking on it's implication.

Parents
  • 0

    I have some update. 

    First of all thanks for bringing this to our attention, There is an internal work ongoing to make this workaround into the SDK. 

    Are you using TF-M ?

    • yes - we can’t really provide anything ad-hoc as the workaround must be applied in secure execution environment, and guiding to modify TF-M locally sounds unfeasible

    • no - meaning the user application executes in secure execution environment so we can provide a patch for any NCS release you might be using that would modify in-tree nRF53 boot code to apply the workaround when specific Kconfig is enabled (basically cleaned-up version of existing draft: zephyr: soc: nordic: nrf53: add support for anomaly 166open 

    Initial roadmap for proper in-tree fix would be NCS 3.5.0 (cannot guarantee that). This way we can apply the workaround properly for both secure (non-TFM) and non-secure (TFM-enabled) applications.

Reply
  • 0

    I have some update. 

    First of all thanks for bringing this to our attention, There is an internal work ongoing to make this workaround into the SDK. 

    Are you using TF-M ?

    • yes - we can’t really provide anything ad-hoc as the workaround must be applied in secure execution environment, and guiding to modify TF-M locally sounds unfeasible

    • no - meaning the user application executes in secure execution environment so we can provide a patch for any NCS release you might be using that would modify in-tree nRF53 boot code to apply the workaround when specific Kconfig is enabled (basically cleaned-up version of existing draft: zephyr: soc: nordic: nrf53: add support for anomaly 166open 

    Initial roadmap for proper in-tree fix would be NCS 3.5.0 (cannot guarantee that). This way we can apply the workaround properly for both secure (non-TFM) and non-secure (TFM-enabled) applications.

Children
Related
Terms of service