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.

AM2434: I2c not responding after continuous run for 1 Hr

Part Number: AM2434

Hi 

We are running AM2434 custom boards in daisy chain of 30 cards. we are using sdk ind_comms_sdk_am243x_09_02_00_24 

After running for approximately 4 hours, Few EtherNet/IP (EIP) cards stop responding to PLC commands. Specifically, the Run/Stop command and speed change are not responding, even though the cards still appear online in PLC. Additionally we checked the prinf function is not getting invoked.

The Run/Stop and speed update functionality is handled in a separate DAC task,  where we invoke
I2C_transfer(i2cHandle, i2cTransaction); every 30 ms inside SOC_dac_process. Is it possible for the system to get stuck inside I2C_transfer()? Also, is a 30 ms interval sufficient to reliably complete the I2C_transfer() operation? 

 

Here task reference.

image.png

  • Hi,

    Have you configured I2C in blocking mode? If yes, we do wait for semaphore variable to get post after the transfer completes.

    Regards,

    Tushar

  • Yes, the I2C peripheral is configured in blocking mode, as we must refresh the DAC output every 30 ms. I’d appreciate guidance on the recommended approach to guarantee that I2C_transfer() is invoked consistently at this 30 ms rate.
  • Try configuring the timeout value for I2C transaction to not wait for infinite time. The default value used for timeout is SystemP_WAIT_FOREVER.

    The I2C_transfer() API uses Semaphore_Pend API with timeout value configured in the I2C transaction variable. Configure the timeout value with appropriate timeout to guarantee I2C_transfer() return in deterministic time. The I2C_API will return the success/failure status based on the operation completion.

  • Hi,

    We already using the timeout i2cTransaction->timeout = ClockP_usecToTicks(20000);

    We also verify the return status, but the I2C_transfer() call is returning -1.


    From reviewing the I2C driver, I2C_recoverBus() seems to handle only timeout‑related issues. What should we expect if the failure is caused by something other than a timeout?
    Is there any recovery mechanism for non‑timeout errors, or any recommended way to diagnose these failure conditions?
    Also, is it acceptable to re‑initialize the I2C peripheral from the application side after a few retries (e.g., after 3 failed attempts)?


  • You can check the value of intStatusErr variable of the I2C_Object for any other I2C errors.

    Is there any recovery mechanism for non‑timeout errors, or any recommended way to diagnose these failure conditions?
    Also, is it acceptable to re‑initialize the I2C peripheral from the application side after a few retries (e.g., after 3 failed attempts)?

    Please refer to the below note mentioned in TRM. If the SCL is stuck low, a bus reset is required for normal operation.

    Or If SDA is stuck low, wait for 9 clock pulses for SDA to be released otherwise reset the I2C IP.

    The I2C_lld_recoverBus() API does the above.

  • Hi,

    currently we are using this way for i2c recover. But still, we see the same behavior. can you update me is there any possible debug step which we can make here.

  • Do you mean after re-initializing the driver also, you are not able to perform the I2C transaction?

    Please try modifying the files (i2c_v0_lld.c, i2c_v0.c) with below provided files.

    Files - i2c_v0.ci2c_v0_lld.c

    Once the above mentioned changes are done, rebuild the libraries and example project.

    Please let us know the results.