How to apply errata 254 correctly with variable FEM?

[SebastianA]

We are trying to implement errata 254, but I've run into a couple of questions.

What's the correct test to see if the device needs the workaround for the errata? NRF_FICR->INFO.VARIANT > 0x414145ffUL ?

Is there a drawback to always use this work around, even without a FEM or with it in bypass mode?

How should the errata be handled when we only sometimes use the FEM? We use nRF5 SDK and Softdevice S140 (currently v7.2.0) and normally put the FEM in bypass mode when Softdevice might use the radio with BLE. The first code block in the errata, should it not be reverted in some way then?

If we use a PA with 8dBm amplification, but send at 0dBm, should we still use the work around? Is there a specific power level when it should be used?

I saw the implementation in the nRF Connect SDK. It seems the work around is actually never used there, but the implementation of the errata simplifies the code blocks to only check the 0x10000334 register, before updating both registers. Is that a correct way to handle it? It also doesn't implement the switch back to non-802.15.4 mode. How's that handled there?

[Kenneth]

Hello,

Regarding this errata:
https://infocenter.nordicsemi.com/topic/errata_nRF52840_Rev3/ERR/nRF52840/Rev3/latest/config_840_254.html 

This errata is only implemented in NCS v1.7 and later, and the if() statements in the errata will ensure the code is only executed on the revisions that require/use the errata to be applied. Do not apply the code inside the if() statements on older parts.

The workaround is not compatible with the softdevice. Typically the radio is power cycled frequently by the softdevice or other radio protocols, so there is no easy way the workaround can be applied manually by the application. That is why you need to use an NCS release that implement the workaround described.

I would like to say that the errata do say "might violate", so the design may pass without the workaround and older SDK, the workaround will for new parts and NCS v1.7 and later ensure better margin. If you are using an older SDK and the designs do fail, then you will need to consider either updating to NCS v1.7 or design-in a band-pass filter.

Best regards,
Kenneth

[SebastianA]

Ok, so we don't need more checks than is already in the errata's workaround and it can be run on rev-1 & 2 chips without a problem? Great.

We make an operating system and meshing network stack that other companies use with their hardware. We want to offer them an easy upgrade path to your new chip revisions so they can protect their IP. Asking them to redesigning the hardware or switching to Zephyr for existing designs isn't an option.

We always put the FEM in bypass mode when Softdevice is using the radio. If we run the last code block in the workaround after we've used the IEEE 802.15.4 mode, wouldn't that be enough?

[Kenneth]

SebastianA said:

Ok, so we don't need more checks than is already in the errata's workaround and it can be run on rev-1 & 2 chips without a problem? Great.

Just to make sure there is no misunderstanding: Any revision of the nRF52840 yes.

SebastianA said:

If we run the last code block in the workaround after we've used the IEEE 802.15.4 mode, wouldn't that be enough?

When the softdevice stack take control over the radio during a BLE event, it will always power cycle the radio to ensure the radio return to default state before it will configure the radio. This power cycling will remove any configuration and state of the radio, so adding the last code block that will clear the workaround for 802.15.4 will very likely be redundant, but it is nothing wrong with having it there either.

Best regards,
Kenneth