82574L EEPROM corruption

[PDorm]

Hi all,

I am investigating an EEPROM corruption issue that happens with this 82574L device.

Environment: WES7, latest drivers

Symptoms: (various applies)

1) Device cannot start (Code10)

2) Device found as a second device (# 2 ending)

3) Device not found

Cause:

Corrupted NVM image (AT25320 - 32kx8 used). The corruption so far look like that zero bytes written to random addresses and depending where it is written it causes different effects.

What was strange that in most of the cases the zero bytes appeared at those addresses what the controller loads during startup.

Root cause: unknown yet

Theories: (Here I would need more ideas to check)

1) EEP Read command on the SPI bus recognized as write (due to disturbance), and as the SI is zero during read, it overwriting those locations

-missing part of this explanation: how the EEPROM becomes write enabled? After each write the EEP shall be write enabled again, and the controller only issuing status request (16 clock cycle) and read command (32 clock cycle). The write enable is 8 clock cycle, so even if a read or status request command corrupted and becomes WREN its unlikely that it will get the ChipEnable high in the correct time.

2) Intel driver "doing something"

Has somebody met with similar problem before by using this controller?

I would appreciate any ideas.

Thank you in advance!

[SYeo3]

Hi DP86,

Thank you for contacting Intel.

For corrupted Eeprom, reflashing the image may recover the controller. Please refer to this article on how to update the boot agent.

http://www.intel.com/support/network/adapter/pro100/bootagent/sb/CS-008362.htm How to Update Intel® Boot Agent

Hope this is helpful. If you continue to encounter this error, we suggest to contact your system manufacturer for assistance.

Sincerely,

Sandy

[PDorm]

Hi Sandy,

I am more interested in finding root cause of the problem as there is a lot of device on the field is affected.

Once the Vendor ID/Subsystem ID overwritten by zero the device is not recognized and I saw no chance in this case to update the EEPROM. (We are speaking about SW solutions, replacing the CPU module all the time is not so cost effective).

As I saw only bytes overwritten by zero bytes (compared to the golden image) it means that the EEPROM programmed somehow (as everybody know 0xFF erased, not 0xFF programmed state).

So if it would be noise then I should see not just zero bytes, but other random stuff.

As only Intel is responsible for writing the driver I would need some assistance from them.

Speaking with the system manufacturer about SW/driver is just increasing the message passing nodes by 2-3 and reducing the speed of effective problem solving.

Thats why I am asking community also whether thay have met with the same problem yet or not.

Kind regards,

Peter

[SYeo3]

Hi Peter,

Thanks for writing back. I'll help check on this.

Sincerely,

Sandy

[PDorm]

Hi Sandy,

ok, thank you in advance!

Ah yes, one more additional info: we are using a non-manageable image: MNGM=00.

[SYeo3]

Hi DP86,

Thanks for your reply.

Upon checking, we recommend to contact your system manufacturer. Because integrating and configuring these controllers differs between different manufacturers to customize the boards.

However, if you would like us to check on this, kindly contact our Customer Support team. Please find contact details below:

http://www.intel.com/p/en_US/support/contactsupport Contact Intel Customer Support

Have a great weekend!

Sincerely,

Sandy

[AdeJa1]

@PDorm​ At a risk of bringing a 5 year old thread back from the dead - did you ever find out why the NVM was corrupted in your 82574 application? We have the same problem in our product and Intel has the same blameshifting strategy in our case. It is possible to reprogram the EEPROM, but I'd like to understand the root cause since I'd like to prevent it from happening with customer units.