How to check anomaly status in NCS documentation ?

[Romain]

Hi,

We are going through the errata file (nRF52840 rev 2) and wonder how to link anomaly (chip level) with nRF Connect SDK release (RTOS level)...

Where to find the information in https://developer.nordicsemi.com or https://infocenter.nordicsemi.com ?

The errata file sometime refers to MDK version or Soft Device version but I don't know what to do with this according to NCS.

Here is a list of anomalies that we would check if workarounds are in place or if they still have to be done by ourself: 36,78,81,87,136,153,172,173,191,209,210,213,214,233,246

Config: NCS 1.6.0 and higer, nRF52840 rev 2

Best regards,

Romain

[Edvin]

Hello,

I don't think there is a simple overview of these, but if you check the file file system_nrf52.c in your NCS version, you can see whether you can find a portion of them or not. You can see e.g. Errata 36:

    #if NRF52_ERRATA_36_ENABLE_WORKAROUND
        /* Workaround for Errata 36 "CLOCK: Some registers are not reset when expected" found at the Errata document
           for your device located at https://infocenter.nordicsemi.com/index.jsp  */
        if (nrf52_errata_36()){
            NRF_CLOCK->EVENTS_DONE = 0;
            NRF_CLOCK->EVENTS_CTTO = 0;
            NRF_CLOCK->CTIV = 0;
        }
    #endif

So try searching for NRF52_ERRATA_NN_ENABLE_WORKAROUND in NCS (mainly in that file) to see whether they are implemented. 

Those that you don't find using the NRF52_ERRATA_NN_ENABLE_WORKAROUND, you can search for USE_WORKAROUND_FOR_ANOMALY_NN.

I see that some of them are clearly implemented, such as 36 and 136, which are mentioned in system_nrf52.c. A few others are implemented in their respective drivers, such as 241 (I know you didn't list that one) is implemented directly in the driver. Search for "USE_WORKAROUND_FOR_ANOMALY_201".

Some were never implemented in any driver files, such as 213. This is something that needs to be applied in the application. Some of them are a bit more tricky to figure out whether or not are actually implemented, such as 172, as this can't be applied directly in the Softdevice Controller, like you could in the Softdevice. I am not sure whether or not it is implemented in the softdevice controller (but I suspect that it is). I need to check this internally. I will also try to figure out whether there is a simple way of seeing what anomalies that are already implemented in NCS, and which ones you need to implement in your application.

Best regards,

Edvin

[Romain]

Hi Edvin,

Thanks this is a nice starting point but indeed I found only 36 and 136 looking after the 2 definitions you gave.

Looking forward to hearing from you about further tips.

Best regards,

Romain

[Edvin]

Hello,

Sorry for the late reply. It doesn't look like we have any easy way to look up these. I have received that the softdevice related anomalies are taken into the Softdevice Controller in NCS. Some of the anomalies that have a specific fix in the MDK are also brought into NCS. The MDK fixes apply to the MDK version that is mentioned in the errata/anomaly, and all versions after that. The MDK version that is used in a particular NCS release is mentioned in NCS\modules\hal\nordic\nrfx\mdk\nrf.h through the indicator macros:

/* MDK version */
#define MDK_MAJOR_VERSION   8 
#define MDK_MINOR_VERSION   40 
#define MDK_MICRO_VERSION   2 

(8.40.2 is for NCS v1.7.1).

Then some of the anomalies are not implemented in the SDK, such as some peripheral anomalies that will only trigger under certain conditions. In those cases, the workaround typically mentions what you need to do in that particular case.

Best regards,

Edvin

[Edvin]

Hello Romain,

Sorry for the late reply. 

Our SDK team replied, but it got lost in my backlog. 

They came back with a list of your mentioned errata/anomaly list:

I'll exclude 36 and 136, as these are already taken care of.

 

78:  Documented indirectly at http://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfx/drivers/timer/driver.html#c.nrfx_timer_disable. Elsewhere: It The code in most places takes into account this errata recommendation and use the TIMER SHUTDOWN task instead of the STOP. Although the NRF_TIMER_TASK_STOP may be used in the open-source BLE controller in Zephyr.

81:  This only affects debugging. No workaround implemented.

87:  Not sure how to implement. You can try to implement the snippet from the anomaly workaround directly after using the FPU.

153: This needs to be handled in the application. No workaround provided other than description in the errata/anomaly.

172: Implemented in the Softdevice Controller. At least in 1.7.1. Not sure what version it was implemented (perhaps all).

173: No workaround available. However, this fix can be applied from the application level. 

191: Implemented in the Softdevice Controller. At least in 1.7.1. Not sure what version it was implemented (perhaps all).

209: No workaround in NCS, but can be handled from application. Look out for symptoms in peripheral drivers.

210: No workaround in NCS, but can be handled from application. Look out for symptoms in peripheral drivers.

213: No workaround available. However, this fix can be applied from the application level if symptoms are detected. 

214: No workaround available. However, this fix can be applied from the application level if symptoms are detected. 

233: No workaround in NCS, but can be handled from application. Look out for symptoms in peripheral drivers.

246: No workaround available. However, this fix can be applied from the application level if symptoms are detected. 

I don't know how your work on the application is going. Did you encounter any specific issues with any of the anomalies?

Best regards,

Edvin

[Romain]

Hello Edvin,

Thank you for the detailed response.
We have release a first production version and for the moment we don't have identified any issues about anomalies of the list.

Best regards,

Romain