nRF52810 and errata 185

I am currently evaluating the differences between nRF52811 and nRF52810. I am still using the nRF5 SDK.

One difference is in the nRFInitialize function in the startup code at nRF5_SDK_17.1.0_ddde560\modules\nrfx\mdk\ses_startup_nrf52810.s

It seems that none of the the other chipsets have the following code included:

nRFInitialize:
  /* Workaround for Errata 185 RAM: RAM corruption at extreme corners 
   * found at the Errata document for your device located
   * at https://infocenter.nordicsemi.com/index.jsp */
  
  LDR     R0, =0x10000130
  LDR     R0, [R0]
  LDR     R1, =0x10000134
  LDR     R1, [R1]
  
  CMP     R0, #0xA
  BNE     skip
  CMP     R1, #0x0
  BNE     skip
  
  LDR     R0, =0x40000EE4
  LDR     R2, [R0]
  LDR     R3, =0xFFFFFF8F
  ANDS    R2, R2, R3
  LDR     R3, =0x00000040
  ORRS    R2, R2, R3
  STR     R2, [R0]
  
skip:
  b afterInitialize

I tried to find more information about the mentioned errata 185, but failed.

The list of erratas at https://infocenter.nordicsemi.com/topic/errata_nRF52810_Rev3/ERR/nRF52810/Rev3/latest/err_810.html does not contain errata 185 and searching around the DevZone did not provide any useful results either.

Can somebody please share some more information about errata 185 and maybe explain why only nRF52810 is affected, but none of the other chipsets that may be similar?

While looking for answers I noticed that all the functions that check if an errata is applicable access registers 0x10000130 and 0x10000134 from the FICR. Unfortunately these are not explained in the product specification.

Can somebody please also share some information about these "secret" registers as well?

  • Hi,

    The code snippet  you have found in the MDK is a workaround for an undocumented issue that only exist in revision 1 of the nRF52810. It does not exist in revision 2, nor in any other nRF52 devices.

  • Thank you very much for your answer. But in any case this information is missing from the list of erratas and for the sake of completeness it would be nice to have that information up-to-date.

    Can you also comment on these "magic" registers that are used in the errata functions for checking if a device is affected or not?

  • Hi,

    This erratum is not officially documented, so I cannot say much about it. But the workaround is effective, and is only applied to revision 1 devise, which has not been produced for a long time.

    Regarding the magic registers 0x10000130 and 0x10000134 there are also not documented, but you can see from how they are used extensively in the MDK (nrf52_erratas.h) that this contains information used to determine if a specific errata workaround applies to the device or not, and this has to do with device type and revision.

  • I understand that not every aspect of the device is disclosed to the public in the datasheet. However:

    but you can see from how they are used extensively in the MDK (nrf52_erratas.h) that this contains information used to determine if a specific errata workaround applies to the device or not, and this has to do with device type and revision.

    Exactly because these registers are used to check device type and revision it makes them important registers that are necessary when you want to manually check this information in your own application for example.

    Of course you can argue that this is all handled by the SDK and that customers should not worry, but there are people out there that like to understand and handle these things even at this very low level.

    So if you could raise awareness for this internally this would be great - I would appreciate if these register would be disclosed to the public as well.

    Thanks for your answers, from my side this ticket can be closed.

Related