The system couldn't boot normally when we add an external eeprom on the i2c bus 0

We made the custom carrier board which add en external eeprom 24C16 on the i2c bus 0. As i know the default internal eeprom of Jetson nano is on the i2c bus 2.
The system couldn’t boot normally and we could’t flash all of the system in the recovery. The log of serial show that the product id is an invald 65535.
The system boot after we remove the 24C16 on the i2c bus 0. We do another test that clone content of the internal eeprom of Jetson nano to the eeprom on the i2c bus 0, the system boot normally too, and product id change to 3448 in th log.

hello rd1,

please also check Jetson Nano Product Design Guide for reference.
thanks

I have read the I2C segment of the Jetson Nano Design Guide. I don’t find there is any mention about address conflict on I2C0.

hello rd1,

please also check Board Configuration session.
may I know what’s your use-case, an EEPROM ID for your custom board is not required.
thanks

Hi, we need a 2KB eeprom save all of the uniform informations for all kinds of our production in the factory.

hello rd1,

it’s board-id for EEPROM. You don’t need to specify an EEPROM board ID for your carrier board.

@JerryChang The EEPROM mentioned in this topic is not used to save the board ID but to save the user configurations. It is related to the production use cases and nothing to the board ID. Please help to answer why this kind of EEPROM in the I2S0 bus blocks the system boot. Thanks.

What’s voltage level of your eeprom device I2C port? It should be 3.3V for I2C0 and 1.8V for I2C2.

The voltage level is right: 3.3V for I2C0 and 1.8V for I2C2.

Do you mean your eeprom device can be tolerance with 3.3V and 1.8V? What’s voltage level of your eeprom device I2C port?

Sure, the EEPROM can be tolerant with 3.3V and 1.8V. Both 3.3V and 1.8V can be used for the I2C port. Maybe this issue is not related to the voltage. The test results show that when no data in the I2C0 EEPROM, the system can not boot. But when the data of I2C2 EEPROM in the core module are copied to the I2C0 EEPROM, the system can boot up well. So this is very confusing and maybe it means that there is some limitation when using some EEPROM device by I2C0.

Can you use an oscilloscope to measure and share the waveform of I2C0 with and without EEPROM?

hello rd1,

please setup a serial console to gather bootloader logs for reference,
we need more details to check why EEPROM in the I2S0 bus blocks the system boot.
thanks