AM2434: EEPROM memory in AM2434

Hello Surabhi

Thank you.

Can you confirm if the EEPROM you are referring is the ONE that stores the EVM information?

Can you elaborate the use case for the EEPROM on the custom board.

Please share additional information on the EEPROM connections. A schematic will help.

surabhi jain said:

To help us further narrow down the potential root cause, could you please provide some clarification on the following:

1. What was the reason for implementing the pre-flashing process for these EEPROM ICs at TI?
2. Could you share the detailed procedure followed for pre-flashing?
3. During volume manufacturing, what is the standard process flow used for programming/flashing these EEPROMs?
4. Are there any verification, validation, or read-back checks performed after flashing during production?

Is there a specific reason you are asking these queries.

I need to check if we have the information that can be shared.

Regards,

Sreenivasa

Hi Sreenivasa,

We are using LP-AM2434 and using the same configuration as ind_sdk for EEPROM. We are saving TCP/IP configuration in the EEPROM which is same as Eval kit LP-AM2434 and ind_sdk. Because of this failure we are not able to read IP address of the board and ethernet/ip is not working, which is our main requirement. That is why we need this EEPROM related information. Could you help us how can we share schematic and other information, because do not want to share it in e2e public forum.

Thanks,

Surabhi

Hello Surabhi

Thank you.

surabhi jain said:

We are using LP-AM2434

I assume you meant A2434 in ALX package..

Please share the schematics over private chat.

For the EEPROM, do you have the WP enabled?

Regards,

Sreenivasa

Hello Surabhi,

Thank you.

Let me review the inputs and comeback.

Can you please describe the EEPROM write process you are following.

surabhi jain said:

An issue observed during manufacturing testing. We are using AM2434 and EEPROM used is AT24C. At the manufacturing site some samples are failing and the failures appear to be related to the EEPROM.

Can you please elaborate the issue and the ratio of fail to pass.

Regards,

Sreenivasa 

Hello Surabhi,

surabhi jain said:

An issue observed during manufacturing testing. We are using AM2434 and EEPROM used is AT24C. At the manufacturing site some samples are failing and the failures appear to be related to the EEPROM. During the previous discussion it was told that EEPROMs are pre flashed before mounting in the board. Wanted to know why these EEPROM ICs are pre programmed. 

Please add a link to the thread you are referencing here.

Regards,

Sreenivasa

Hi Sreenivasa,

In this link it is mentioned about preflashed EEPROM - 
RE: AM2434: Mac address mismatch in ind_comms_sdk_am243x_2026_00_00_06

Ratio of fail to pass is 15%.(approx 13 out of 85 fail).

Thanks,

Surabhi

Hello Surabhi,

Can you elaborate the EERPOM programming procedure you are following.

surabhi jain said:

During the previous discussion it was told that EEPROMs are pre flashed before mounting in the board. Wanted to know why these EEPROM ICs are pre programmed. 

The above is the process followed to program TI MAC address.

I am assuming you have your own MAC address that you are programming.

Regards,

Sreenivasa

Hi Sreenivasa,

We didn't change anything in the EEPROM programming procedure from the original sdk ind_comms_sdk_am243x_09_02_00_24\examples\industrial_comms\ethernetip_adapter_demo\profiles\generic_device\standard\rgmii\am243x-lp\r5fss0-0_freertos. 

We are using the same thing as example project. Our understanding is, If we change the IP address of the device it is going into the EEPROM. but because of this failure we are not able to read IP address of the board. 

During trouble shooting of failed boards - 

• we have tried to readback EEPROM memory.

• Page Programming of the EEPROM AT24C is limited to 256 bytes per page. In example code -

  Page 2 is 00200h to 002FFh

  Page 3 is 00300h to 003FFh
• only first 256 bytes of data present starting from 0x200, next 99 bytes are 0xff i.e it’s not written from 0x300 in failed boards.
• In board.h file it is mentioned - #define APP_NVM_CONFIG_OFFSET   (0x200u) //starting address of nonvolatile EEPROM memory

Our understanding is correct or not, or is there anything else related to EEPROM memory. Could you please help us on that. 

Thanks,

Surabhi

Hello Surabhi,

Thank you.

The EEPROM on the EVM are pre-flashed.

I assume you are populating an EEPROM and writing to the EEPRM as part of the board build or bring-up.

Can you please confirm if i understand correct.

I will reassign to the software expert to support.

Regards,

Sreenivasa

Hi Sreenivasa,

we are not writing separately in EEPROM, its part of firmware flashing only.. We are just flashing the firmware and checking the IP address in our custom board.

Thanks,

Surabhi

Hi Surabhi,

The EEPROMs come pre-populated when taken from the TI inventory (from the boards). The standard AT24C doesn't come with the MAC addresses pre-flashed. Please confirm if the EEPROMs are picked from existing evaluation boards, or if they are new parts. If the MAC addresses are needed, then there are other part numbers which come with the MAC addresses preflashed

If the EEPROM is empty, which they should be for the production usecase, you should re-write the EEPROM region/MAC address population logic to ensure you are updating the MAC addresses which are allocated to your manufacturer ID.

surabhi jain said:

• What was the reason for implementing the pre-flashing process for these EEPROM ICs at TI?
• Could you share the detailed procedure followed for pre-flashing?
• During volume manufacturing, what is the standard process flow used for programming/flashing these EEPROMs?
• Are there any verification, validation, or read-back checks performed after flashing during production?

AM243x boards come with multiple instances of ethernet peripherals, and these should have their own MAC addresses for unique identification. Since these are also part of evaluation modules, the MAC addresses should be allocated from the TI allocated MAC addresses, and will be flashed into the EEPROM from TI to enable the customers to run the demos and examples seamlessly.

During volume manufacturing, the manufacturer/vendor should populate their own MAC addresses into the EEPROMs that are used on the boards. The EEPROMs can be flashed by the manufacturer during the production process, either directly onto the IC, or through a start-up process where the boards are initialised with the default data.

The verificstion/validation steps are to be done by the manufacturer's discretion to ensure the data is readable as a sanity check. The extent of testing may vary.

Please let us know if you need more information regarding the EEPROM.

Thanks and regards,
Teja.

Hi Teja
We are currently investigating an EEPROM-related issue observed in our PPAP samples and would appreciate your inputs on the possible root cause. Out of 83 boards tested, we have observed this issue on 11 boards. Upon reviewing the EEPROM communication waveforms, we noticed some deviations on the SDA line. 

For Ethernet-related configurations, we write 355 bytes of data into the EEPROM. As part of debugging, we removed and interfaced the EEPROM from the affected boards with an Arduino setup to verify the data being written. We found that on all the affected boards, only 255 bytes of data (one page) were being programmed, even though the intended write size was 355 bytes. 

To further investigate, we performed a complete erase of the EEPROM contents using the Arduino setup and then rewrote the full 355-byte configuration data. In this case, the write completed successfully. We then soldered the same EEPROM devices back onto our board and repeated the flashing process. After this, the boards functioned normally without any issues. 

We also observed that when writing data smaller than a single page using the Arduino setup, writes succeed even without erasing the existing contents. However, the issue is seen when attempting to write data that spans beyond a single page boundary. 

Another observation is related to the EEPROM WP (Write Protect) pin. In our schematic, the WP pin is left floating. When we replicated the setup using the Arduino board, we were unable to perform write operations when the WP pin was left floating. However, after pulling the WP pin low, writes completed successfully. Interestingly, on the good samples, write operations could still be performed under the same setup even with the WP pin left floating. This inconsistency has raised questions about the potential impact of the WP pin state on the observed behavior. 

As a workaround, we have implemented an erase followed by a rewrite of the EEPROM contents in the firmware, which has resolved the issue in our testing. Additionally, in our samples we have ensured that the EEPROM WP pin is pulled low rather than left floating. With these changes, we are no longer observing the problem. However, we would like to understand the actual root cause rather than relying solely on the workaround. 

At this point, we suspect a page-handling issue in the firmware during multi-page EEPROM writes.  The fact that the issue appears only when data crosses a page boundary seems to support this hypothesis, although we cannot rule out any interaction with the WP pin behavior. 

Could you please review  and share your thoughts on:
•  The possibility of a page-boundary or multi-page write handling problem.
•  Whether the floating WP pin could contribute to the observed behaviour.
•  Any other potential causes that could explain why only the first 255 bytes are being programmed on the affected boards.

Thank you

Surabhi

Hello Surabhi

Please refer below, snipped from the EEPROM data sheet

surabhi jain said:

Another observation is related to the EEPROM WP (Write Protect) pin. In our schematic, the WP pin is left floating. When we replicated the setup using the Arduino board, we were unable to perform write operations when the WP pin was left floating. However, after pulling the WP pin low, writes completed successfully. Interestingly, on the good samples, write operations could still be performed under the same setup even with the WP pin left floating. This inconsistency has raised questions about the potential impact of the WP pin state on the observed behavior. 

Write Protect (WP): The Write Protect input, when connected to GND, allows normal write operations. When WP is connected high to VCC, all write operations to the memory are inhibited. If the pin is left floating, the WP pin will be internally pulled down to GND if the capacitive coupling to the circuit board VCC plane is 3pF, Atmel recommends connecting the pin to GND. Switching WP to VCC prior to a write operation creates a software write protect function.

The recommendation is to always have WP pulled down to be able to write since the internal pulldown has layout dependency.

Regards,

Sreenivasa

Hello Surabhi

surabhi jain said:

For Ethernet-related configurations, we write 355 bytes of data into the EEPROM. As part of debugging, we removed and interfaced the EEPROM from the affected boards with an Arduino setup to verify the data being written. We found that on all the affected boards, only 255 bytes of data (one page) were being programmed, even though the intended write size was 355 bytes. 

To further investigate, we performed a complete erase of the EEPROM contents using the Arduino setup and then rewrote the full 355-byte configuration data. In this case, the write completed successfully. We then soldered the same EEPROM devices back onto our board and repeated the flashing process. After this, the boards functioned normally without any issues. 

We also observed that when writing data smaller than a single page using the Arduino setup, writes succeed even without erasing the existing contents. However, the issue is seen when attempting to write data that spans beyond a single page boundary. 

Please read the below section of the data sheet where the rollover happens when writing more than a page.

Page Write:

The 1-Mbit EEPROM is capable of a 256-byte Page Write. A Page Write is initiated the same way as a Byte Write, but the microcontroller does not send a Stop condition after the first data word is clocked in. Instead, after the EEPROM acknowledges receipt of the first data word, the microcontroller can transmit up to 255 more data words. The EEPROM will respond with an acknowledge after each data word is received. The microcontroller must terminate the page write sequence with a Stop condition (Figure 8-2) and the internally timed write cycle will begin.

The data word address lower 8 bits are internally incremented following the receipt of each data word. The higher data word address bits are not incremented, retaining the memory page row location. When the internally generated word address, reaches the page boundary, the following byte is placed at the beginning of the same page. If more than 256 data words are transmitted to the EEPROM, the data word address will “roll over” and previous data will be overwritten. The address “rollover” during write is from the last byte of the current page to the first byte of the same page.

Writing in multiple pages may need to be handled by the host software. 

Teaja, any thoughts if the driver supports handling multiple page write (since this is use case dependent, customer may need to implement)

Regards,

Sreenivasa