Post Go back to editing

ADIN2111: are SRAM ECC errors (TX_ECC_ERR) expected?

Category: Hardware
Product Number: ADIN2111


I'm testing custom, prototype board with ADIN2111. I'm using SPI mode with CRC for communication. At irregular intervals (sometimes minutes, sometimes hours, probably depending on number and/or size of the packets) reading STATUS1 register returns value with TX_ECC_ERR bit set (most of the traffic is directed from SPI to 10BASE-T1L port). At the same time value of CECC_ERR4 (number of corrected ECC errors in TX FIFO from the host) is often (but not always) non-zero. According to datasheet TX_ECC_ERR seems to indicate uncorrectable ECC error in internal FIFO SRAM.

Are SRAM ECC errors expected or are they rather symptoms of some other issue(s)? Unfortunately I do not have evaluation board to compare.

Could this be related to using SPI mode rather than Open Alliance mode?

More observations:

  • after this event TX FIFO seems to be no longer handled - after few next packets there is no space available; clearing TX_ECC_ERR is not helping and  clearing TX FIFO with LES_FIFOS_CLR allows to fill TX FIFO only once (FIFO is still not handled)
  • sometimes right before this problem happen ADIN2111 reports invalid size of available free space in TX FIFO (as if FIFO size doubled to 4 kB to 8 kB)

Added more observations.
[edited by: tomeko at 9:45 AM (GMT -5) on 10 Jan 2024]
  • Hi Tomeko,

    1. I'm understanding that you are trying to use Open Alliance SPI, is that correct? If so, ensure the SPI_CFG1 and SPI_CFG0  hardware configuration pins are set correctly. Can you please confirm what they are currently set to?

    2. Are you using non-OS driver from our website? Have you ported this driver to your own MCU or are you using the same MCU as the EVAL-ADIN2111EBZ board?

    Kind regards,


  • I am using SPI with CRC mode at the moment - it seemed to be more often used than Open Alliance. It is also simpler, so it is quicker way to test the board.

    I'm using custom hardware and software. I'm looking for information about observed SRAM ECC errors:

    • are they expected in regular office conditions (if they are, at what rate?), without unusual electromagnetic disturbances?
    • could they be related in any way to software (according to datasheet this seem to be internal chip function)?

    Edit: surprisingly this issue disappeared after increasing SPI frequency from 0.7 MHz to 3 MHz.

  • Hi Tomeko,

    Thank you for your response. I'm glad the issue got sorted out.

    1. No, they are not expected in regular conditions unless the SPI signals are affected by, for instance PCB parasitics, in a way that introduces bit errors to the frame going to the device.

    2. Yes, for instance if the SPI signals from the MCU are, for some reason, not correct or misaligned producing bit errors.

    One thing we did think when reading this thread was if the SPI clock frequency was too high and the signal quality wasn't good. So, we did consider the SPI clock frequency being a possible cause, but in the case it is too high.

    If the SPI frequency is too low, what could happen is that frames are dropped once the FIFOs fill up.

    Have you taken oscilloscope captures of the SPI lines at both cases and see if you can spot something maybe causing the issue?

    Kind Regards,


  • I'm not talking about SPI CRC, according to documentation SRAM ECC is an internal and unrelated chip function. ECC is both written and checked by the chip itself and is capable of correcting single bit errors and detecting double bit errors, in case of TX_ECC_ERR - in SRAM belonging to TX FIFO.

    At the moment I do believe (I have not confirmed it with long enough testing) that this issue was caused by the SPI problem on the host side. It is surprising though that SPI communication (in particular not fully completed write to TX FIFO before CS is deasserted) can cause SRAM ECC errors and partially lock up the chip (stop TX FIFO handling).

  • Hi Tomeko,

    It seems you're making progress. If you come across any additional issues or findings, please update us. 



  • Hi Tomeko, 

    We appreciate the opportunity to assist you with your concerns. If all's resolved or you have the information needed, great! Please close the thread and feel free to start a new one if you require further assistance or wish to share additional thoughts. We'll be closing this thread now.