I210: Device ID 1533 is sometimes 1531

[SHoch]

Dear Intel Community

In our device we have two WGI210IT ethernet controllers and we are facing an issue with them: Very rarley, let's say less than once per 100 boot ups, we see that the device ID is 1531 instead of 1533. At the moment we cannot reproduce it, it just appears sometimes on our devices.

lspci under linux shows it like this:

01:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)

02:00.0 Ethernet controller: Intel Corporation Device 1531 (rev 03)

After a reboot the Ethernet controller has ID 1533 again:

01:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)

02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)

Early at bootup of Linux the following message apears:

kernel: pci 0000:02:00.0: [8086:1531] type 00 class 0x020000

So it we doubt that any operating system related action causes the wrong ID.

The configuration is as follows:

- Ethernet controller firmware: Dev_Start_I210_Copper_SMB_8Mb_A2_3.25_0.03.bin

- Changes in Flash (On some devices done with Lanconf.exe under DOS and in others with eeupdate64e under Linux):

--> Word 0x20: Set bit 4 to '1' (disables Gbit Ethernet)

--> Changed MAC Address

- Gigabit Ethernet is not supported on HW side. MDI_PLUS_2 / MDI_MINUS_2 / MDI_PLUS_3 / MDI_MINUS_3 are pull-up to 1.5V via 49.9R resistors

- Flash: MX25L1606EZNI-12G

- 33R resistors in SPI lines (NVM_SI, NVM_SO, SVM_SK, NVM_CS# )

- Pin 12 is pulled-down with 10k (strap pin --> non secure mode)

Hardware checks:

- The I210 and the flash are powered from the same 3.3V source. First flash access happens after 25ms after 3.3V is reached. The flash itself requires 200us to be ready after Vmin is reached. So the flash is ready at first access.

- The signal levels of all SPI lines are fine.

- The solder points are checked and nothing wrong was seen.

We checked a few register values while the problem was seen:

Read at 0x90012010 | 0x40 0x2A 0x48 0x00 (Base address is 0x90000000)

The 1533 controller shows:

Read at 0x91312010 | 0x40 0x2B 0x08 0x06 (Base address is 0x91300000)

Differences:

EEPROM-Mode Control Register - EEC (0x12010) bit 8 is '0'. --> EE_PRES: No Flash with correct signature or empty iNVM

EEPROM-Mode Control Register - EEC (0x12010) bit 22 is '0'. --> Reserved: No info from datasheet

EEPROM-Mode Control Register - EEC (0x12010) bit 25 is '0'. --> SEC1VAL: Sector 1 not valid (but not meaning full due to bit 8 is '0')

EEPROM-Mode Control Register - EEC (0x12010) bit 26 is '0'. --> FLUDONE: No flash update done

Have you got any idea what could cause this problem?

Thank you in advance and best regards

Stefan

[idata]

HI Stefan,

Just to double check, are you referring to one appeared as 1533 and the other one appeared as 1531 or both? Both 1531 and 1533 are I210 device ID, the 1531 is the hardware default value. Please refer to page 9 of the FAQwww.intel.com/content/dam/www/public/us/en/documents/faqs/ethernet-controller-i210-i211-faq.pdfrgds,wb

[SHoch]

Hi wb

Both I210 should be 1533 all the time. Both have the same firmware.

But sometimes the ID is suddently 1531 after a boot . We have seen this behaviour on both I210.

Best regards

Stefan

[idata]

Hi Stefan,

Thank you for the clarification. I will check on this.rgds,wb

[idata]

Hi Stefan,

Good day. Further checking, we are not able to reproduce the issue, can you help shareany reproducible case/process so that we can be of better assist?thankswb

[idata]

HI Stefan,

Please feel free to provide the process for me to better check.thanks,wb

[SHoch]

Hi wb

Happy New Year!

Thank you for checking on this case.

Unfortunately, we still do not have a procedure to reproduce it to 100%.

All we can do is to start the devices, check automatically the ethernet controller and restart. Sometimes no error occurs for several thousand restart, sometimes the error occures 2-3 times in a row.

We made some investigations on the pull-up/pull-down resistor on Pin 12.

Initially we had 10k PD connected. The datasheet states that the internal PU resistor can be 30k +/-50%. In the worst case, the internal PU and external PD might have given an illegal level (Low level above 0.3x3.3V=0.99V). So we thought that this could be the root cause and changed the PD to 1k. Unfortunately, on some boards it still caused the ethernet controller to not load the firmware and showed ID 1531 again.

Also we changed the 1k PD to a 1k PU, but with the same result.

Any advice how to proceed?

Shall I provide you the schematic part of the ethernet controllers?

Do you need a register dump?

Thanks and best regards,

Stefan

[idata]

Hi Stefan,

Happy New Year too! Thank you for taking time to do further test. I will check what additional information we need. rgds,wb

[idata]

Hi Stefan,

Good day. The 1531 means no valid flash. Do you have a consistently working board VS one that shows failure? If yes, please provide the lot codes of each chip. The lot code can be found in line 2 of the controller. you may refer to page 7 of the spec update http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/i210-ethernet-controller-spec-update.pdfThanks,wb

[idata]

Hi Stefan,

Good day. Please feel free to provide the information requested on my previous postThanks,wb

[SHoch]

Hi wb

Thanks for the reply. Sorry for not answering, but now I'm back at the issue.

We did some further tests on this case:

- We exchanged the flash from our board with a dirfferent one from another board which is not from us and where the same etherner controller is used. --> But the error still occured on our board.

- We changed some capacitors for the quartz. --> Error occured

- We changed the firmware from managed to non managed --> Error occured

- We exchanged the I210 from our board and the 3rd party board. No error occured, not on our board, not on the 3rd party board. So, I cannot conclude much from this, I hoped that the error occures on one of the board. The next point is to solder each I210 back to their original boards, to see if the error comes back.

We are still not able to reproduce, it is still by chance.

To your question:

I210 where the problem occured: 1619BFP

I210 where the problem did not occur until now: 1429AMP

Thanks and best regards

Stefan

[idata]

Hi Stefan,

Thank you for the information and getting back to us. Can you help clarify the first statement:"We exchanged the flash from our board with a dirfferent one from another board which is not from us and where the same etherner controller is used. --> But the error still occured on our board." Is the flash refers to the I210? What is the different one from another board (is it another I210 used on the third party board)? Looking forward to your reply. Thank you.rgds,wb

[SHoch]

Hi wb

Yes, it is the flash which is attached to the I210.

Both boards use the I210, but with a different flash attached:

- Our board uses: Macronix MX25L1606EZNI-12G

- Third party board uses: Winbond W25Q80DVSNIG

It didn't matter which flash was attached to I210 on our board. The error occured with both type of flash.

Thanks and best regards

Stefan

[idata]

Hi Stefan,

Thanks for the additional information.Rgds,wb

[idata]

Ｈi Stefan,

Further checking, you need to contact our embedded design support for them to better assist on your inquiry. Please visit below website and signed to obtain the support. http://www.intel.com/content/www/us/en/embedded/embedded-design-center.htmlThanks,wb

[SHoch]

Hi wb

I got in touch with the embedded design support.

In case we can resolve the issue I will update this thread.

Thank you for your support

Best regards

Stefan

[idata]

Hi Stefan,

Thanks for the reply. Hope to hear good news from you.rgds,wb

[UFink]

Hi all,

We experience the same behaviour in one of our designs (not all boards affected and the error occurs randomly on affected boards).

Is there any hint how the issue has been fixed by the original poster?

Best regards,

[AHG2022]

We have exactly the same problem. There are around 60 systems in our test center. Each system has 10 x i210it. 
If we turn on the systems in the morning and it is around 0°C, we see that one i210 has the default PCI ID 1531
on 2 to 3 systems:

Class 0200: 8086:1533         
Class 0200: 8086:1533
Class 0200: 8086:1531   <-- 
Class 0200: 8086:1533
Class 0200: 8086:1533
Class 0200: 8086:1533
Class 0200: 8086:1533
Class 0200: 8086:1533
Class 0200: 8086:1533
Class 0200: 8086:1533

These systems then have to be started again (poweroff/poweron, reboot doesn't fix it) and then it's good.
All i210it have the 3.25 firmware in the flash and a current Linux kernel 5.10 is used.

When it's warmer, we've never observed this error.

So I don't think a solution exists.