• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 31 subscribers
  • Views 84 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM2634: I2C CONTROLLER TO CONTROLLER COMMUNATION

TEMC
Intellectual 955 points
Part Number: AM2634

Tool/software:

Hello TI Experts,

I am working with the I2C LLD (Low-Level Driver) on AM263x, using one controller as I2C master and another as I2C slave (target). I am using interrupt mode with a custom ISR for the slave (I2C_lld_targetIsr()).

I noticed that the default ISR implementation provided in the SDK is designed for general purpose usage. However, to meet my application requirements — specifically continuous bidirectional communication between two AM2634 devices — I needed to modify the ISR to:

  • Set custom flags

  • Track internal counters

  • Restart transfers immediately inside the ISR

  • Log or capture data buffers more flexibly

My Questions:

  1. What are the guidelines or best practices for modifying I2C_lld_targetIsr()?
    Are there recommended extension points or protections to preserve driver integrity?

  2. Does modifying the ISR or adding application-specific flags or counters (e.g., setting rx_flag = 1) impact the software’s SIL (Safety Integrity Level) compliance or any safety certification goals?

  3. If my system is being developed for a safety-critical domain (like SIL-2 or SIL-3), are there specific precautions to take when modifying interrupt-level driver code?

  4. Is there a better way to achieve continuous read/write functionality in the target (slave) using existing LLD infrastructure without modifying the ISR?

I would greatly appreciate any insights, references to TI safety manuals or certified driver variants (if any), and guidance on how to structure such modifications safely.

Thank you!

  • 0
    TI__Genius 16502 points

    Hi,

    I don't have any concrete guidelines for modifying the I2C_lld_targetISR, just a few points from my experience:

    1. If you have other higher priority interrupts and expect them to interfere in your I2C transactions, please make sure the slave devices you choose support clock stretching, or else, make sure that when I2C is running, no other interrupt preempts I2C transactions, as it can cause clock stretching.

    2. Keep the ISR minimal and safe

    3. For continuous target mode communication, use ring buffer to collect Tx and Rx data + flag-driven background handler to signal to the main loop. If you need a restart mechanism for transfers, you can either have them in the ISR itself (if you do not wish to be interrupted by other stuff) or call the LLD transfer functions again).

    TEMC said:

    • Does modifying the ISR or adding application-specific flags or counters (e.g., setting rx_flag = 1) impact the software’s SIL (Safety Integrity Level) compliance or any safety certification goals?

    • If my system is being developed for a safety-critical domain (like SIL-2 or SIL-3), are there specific precautions to take when modifying interrupt-level driver code?

    The software in MCU_PLUS_SDK is not safety certified. I do not have any specific inputs w.r.t Safety applications. The safety of software (if you want to write a safety certified software), has to be taken care on your end.

    TEMC said:

    1. Is there a better way to achieve continuous read/write functionality in the target (slave) using existing LLD infrastructure without modifying the ISR?

    Can you let me know what challenges you are facing with the current I2C ISR in LLD? Is it acting unreliable or do you see any communication failing? 

    You can request the AM263x safety manual from here: https://www.ti.com/drr/opn/AM263X-RESTRICTED-DOCS-SAFETY

    Regards,
    Shaunak