This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LMK03318: How could I configure EEPROM via i2c successfully?

Part Number: LMK03318

Hi, 

I refer the document to Write SRAM and EEPROM via i2c, 

In Write SRAM, it looks fine. When I write EEPROM, it have a strange status.

I do step 3 and 5 to check as below:

3. Write a 1 to R137.0. This programs the entire SRAM contents to EEPROM. Once completed, the contents in
R136 will increment by 1. R136 contains the total number of EEPROM programming cycles that are
successfully completed.

4. Write 0x00 to R144 to protect against inadvertent programming of EEPROM.

5. If an EEPROM write is unsuccessful, a readback of R137.5 results in a 1. In this case, the device will not
function correctly and will be locked up. To unlock the device for correct operation, a new EEPROM write
sequence should be initiated and successfully completed.

In step 3: I see R136 is increment by 1.

In step 5: I see R137.5 is not resulting in a 1, so I believe  it is successfully. 

strange status is as below:

because I configure a wrong value to EEPROM for clock gen, so I could not found MAC device via PCIe.

but when I "power cycle", it is still normal to found MAC device via PCIe.

It represent I don't  configure to EEPROM successfully, but the step 5 is still successful completed.

Do you have any idea?

Best Regards

Ruihong sun

  • Hello Ruihong,
    Your request is assigned to an expert and he will get back to you very soon.
    Best regards
    Puneet
  • Hello,

    How do you intentionally "configure a wrong value to EEPROM"?  What are you trying to accomplish by doing that?

    The device automatically computes the CRC value from the NVM data when you Program EEPROM with NVMAUTOCRC bit set.  So you should not get a wrong value to EEPROM by following the procedure you used, unless you intentionally clear the NVMAUTOCRC bit before programming EEPROM.

    Alan