SystemInit() errata workarounds executed twice per power-up cycle (nRF5 SDK 16.0.0)

[Joeri]

Hello,

We have a question about the errata workarounds applied in SystemInit() in nRF5 SDK v16.0.0.

Our firmware is split into two images: a boot application and a main application. On power-up the device starts in the boot application, which then relocates the vector table and jumps directly to the main application (no system reset in between). As a consequence, SystemInit(), and therefore every errata workaround it contains, is executed twice in a single power-up cycle.

Our questions:

1. Can executing these workarounds twice lead to any unintended behaviour or side effects?

2. If executing them twice is problematic, could you indicate per erratum what action we should take (for example, skipping the workaround on the second execution, or applying it in a specific order)?

For reference, below is the list of errata workarounds we identified in SystemInit() for this SDK version, grouped by the device variants they apply to.

nRF52832 only:
ERRATA_12, ERRATA_16, ERRATA_31, ERRATA_32, ERRATA_37, ERRATA_57, ERRATA_108, ERRATA_182

nRF52832, nRF52833 and nRF52840:
ERRATA_36, ERRATA_66, ERRATA_136

nRF52840 only:
ERRATA_98, ERRATA_103, ERRATA_115, ERRATA_120, ERRATA_217


Thank you in advance for your help.

Best regards,

Joeri

[Edvin]

Hello Joeri,

Interesting question. My gut feeling, since this has been this way since SDK 16.0.0 was released, and we didn't receive (as far as I know) any reports that this has been an issue, I assume it is working fine as it is now. We have a lot of customers with products out in the field using SDK 16.0.0, and almost no customers go to production without a bootloader, so this is not a new use case. Also, typically, the errata workarounds consists of 1: doing something particular before going to sleep, or after you used a peripheral, or 2: to write some specific value to a register. 

For 1: this is handled in the application (or drivers of a particular peripheral), so in this case it doesn't care whether a bootloader ran before the applciation.

For 2: Writing these values to a register two times is also not an issue. If the register already had that value, and you write it again, then nothing changes.

But let me run through the specific erratas that you listed, and I will see if I can find any particular concerns.

nRF52832: 

ERRATA_12: Write to register. OK to do twice.

ERRATA_16: not present in production version of chip.

ERRATA_31: Write to register. OK to do twice.

ERRATA_32: not present in production version of chip.

ERRATA_37: not present in production version of chip.

ERRATA_57: not present in production version of chip.

ERRATA_108: Write to register. OK to do twice.

ERRATA_182: Done specifically after using a peripheral. Doesn't care about bootloader/application.

ERRATA_36: Write to register. OK to do twice.

ERRATA_66: Write to register. OK to do twice.

ERRATA_136: Write to register. OK to do twice.

nRF52840:

ERRATA_98: not present in production version of chip.

ERRATA_103: not present in production version of chip.

ERRATA_115: not present in production version of chip.

ERRATA_120: not present in production version of chip.

ERRATA_217: not present in production version of chip.

Many of these were not listed in the production versions of the chip. I only checked e.g. Revision 1 Errata, Revision 2 Errata and Revision 3 errata for the nRF52840 Errata. I did not check the Engineering A-D, but you will not be using these either way. The same for nRF52832/33. Not sure how you found these. Perhaps references in the source code, but there should be a check ensuring that these are not applied if you are using Rev1-3 of the different chips.

Best regards,

Edvin