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.

[参考译文] AM263X-MCAL SDK:查询 AM2634 LaunchPad 上 I2C1 扫描结果

Guru**** 2815985 points

Other Parts Discussed in Thread: LP-AM263, AM2634, SYSCONFIG, TPIC2810

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1625023/am263x-mcal-sdk-query-regarding-i2c1-scan-results-on-am2634-launchpad

器件型号:AM263X-MCAL SDK
主题中讨论的其他器件: AM2634、LP-AM263、 SysConfig、TPIC2810

尊敬的团队:

我使用的是 AM2634 LaunchPad 套件、 根据用户指南和电路板原理图、我了解 I2C1 总线上连接了两个器件:EEPROM 器件和 LED 阵列器件、并具有预期的 I2C 地址 0x52 0x61

但是、当我在 I2C1 总线上执行 I2C 扫描时、将获得以下地址:

0x1C、0x52 和 0x53

我还注意到、电路板原理图中的 EEPROM IC 连接似乎与器件数据表中给出的原始 IC 引脚配置不同。 我想知道这是否可能是检测到额外地址的原因。

您能否通过执行来在您的最终验证一次 LP-AM263 硬件上的 I2C1 扫描

如果预期会出现此行为、请说明检测到其他地址的原因。

谢谢。此致、
Sai Kiran

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Sai、

    这些地址对应于 I2C1 总线上的以下器件:

    1. 0x1C - AM2634 器件本身的默认 I2C 地址
    2. 0x52 — 板 ID EEPROM  
    3. 0x61 - LED 驱动器

    我不知道为什么您的 I2C 扫描会读取地址为 0x53 的器件。 您使用的是 SDK 示例还是您自己的代码?

    此致、

    Brennan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    写入
    下面是我们正在使用的代码,请检查一次,任何错误都有,告诉我们!

    #include
    #include
    #include “ti_drivers_config.h"</s>“
    #include “ti_drivers_open_close.h"</s>“
    #include “ti_board_open_close.h"</s>“

    /*
     *这是为器件中的所有内核提供的空工程。
     *用户可以通过添加更多 SysConfig 模块来使用此项目启动应用程序。
     *
     *此应用程序执行驱动程序和电路板初始化,并只在控制台上打印传递字符串。
     *如果是主内核,打印将被重定向到 UART 控制台。
     *对于所有其他内核、使用 CCS 打印。
     */
    char buf[50]
    void I2C_SCAN_Application (void * args)

       uint8_t dummy = 0
      I2C_Transaction Trans;
      /*打开驱动程序以打开控制台的 UART 驱动程序*/
      drivers_open()
      BOARD_DRIVERSOpen ();

      I2C_Transaction_init (&Trans);
       trans.writeBuf =&dummy;
       Trans.writeCount = 1
       Trans.ReadCount = 0
       TRANS.readBuf = NULL
    while (1)

      DebugP_LOG(“I2C 扫描已启动...\r\n“)
     for (int i = 7;i < 127;i++)
     {
       Trans.targetAddress = i;
       if (I2C_TRANSFER (gI2cHandle[0]、 &Trans)== SystemP_SUCCESS)
       {
        DebugP_log(“Slave found at address:0x%02x\r\n“、I);
       }
       
     }
     DebugP_LOG(“\n")“);
     ClockP_SLEEP (1);
    }


      Board_driversClose()
      drivers_close()
    }    
    谢谢、
    S Sai Kiran
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Sai:

    感谢您提供更多信息。 我可以解释一下:

    1) I2C 扫描分析

    • 0x1C–I2C 控制器自己的默认目标地址
    • 0x52 - EEPROM 低位 64KB 组
    • 0x53 - EEPROM 上部 64KB 组

    2) 扫描检测控制器的地址

    I2C 一次在主模式或从模式下运行是正确的。 在扫描过程中、控制器仅在主模式下运行。
    不过:

    1. AM263x I2C 外设有一个默认设置为 0x1C 的自己的地址寄存器 (ICOAR)
    2. 当主器件在总线上传输地址 0x1C 时、硬件的地址匹配逻辑会识别该地址
    3. 这可能会导致内部 ACK 响应、这是器件级行为、不是协议违例
    4. 解决方案:跳过扫描自己的地址、或在 SysConfig 中将其更改为未使用的值

    3) 代码分析

    有几个问题:

    1. 使用 I2C_TRANSFER () 而不是 I2C_PROBE ()
      1. SDK 专门为器件检测提供 I2C_PROBE ():
      2. int32_t I2C_PROBE (I2C_Handle handle、uint32_t targetAddr);
    2. 不跳过自己的地址 (0x1C)
    3. 验证 I2C 实例是否正确 — 确保 gI2cHandle[0]为 I2C1

     /* Scan addresses 0x08 to 0x77 (valid 7-bit range) */
          for(uint32_t addr = 0x08; addr <= 0x77; addr++)
          {
              /* Skip controller's own address */
              if(addr == I2C_OWN_TARGET_ADDR)
              {
                  continue;
              }
    
              /* Use I2C_probe() for proper detection */
              status = I2C_probe(gI2cHandle[0], addr);
    
              if(status == SystemP_SUCCESS)
              {
                  DebugP_log("Device found at: 0x%02X", addr);
    
                  DebugP_log("\r\n");
              }
          }

    此致、

    Brennan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好 Brennan、

    感谢您先前的反馈。

    这可能会导致内部 ACK 响应 — 器件级行为,不是协议违例

    我理解这一点、但在我使用许多不同的主器件(包括分配从器件地址)的体验中、我从未遇到过器件自身地址的检测问题。 分配从器件地址然后执行主模式扫描的 MCU 或主机中、这种情况是否常见?

    我已经按照您的建议更新了代码i2c_probe、但我仍然看到相同的扫描结果。

    • 为什么我无法检测到地址0x61

    • 0x53扫描中出现的附加地址的来源是什么?

    我还注意到电路板原理图中的 EEPROM IC 连接似乎与器件数据表中给出的原始 IC 引脚配置不同。 我想知道这是否可能是额外检测到的地址的原因。

    您检查过吗、引脚排列似乎错误、如果错了、请纠正我?

    谢谢、

    Sai Kiran

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Sai、

    1) 此行为特定于 TI 的 I2C 外设实现、并非所有 MCU 都通用。

    AM263x 上的 TI I2C 模块有一个自己的地址寄存器 (ICOAR)、该寄存器始终处于运行状态。 与一些其他 MCU 实现方案(在外设模式下只监控自身地址)不同、由于内部总线监控、即使作为控制器运行、TI 的器件也可能会确认自身的地址
    兼容的。

    要消除这种误报、请将 SysConfig 中的自身地址更改为您知道总线上不存在的地址(例如 0x08)、或者直接在扫描循环中跳过 0x1C。

    2) 未检测到 LED 驱动器

    如果您运行任一 I2C LED 闪烁示例(中断或轮询)、您是否能够检测器件并使 LED 闪烁?

    3) EEPROM 检测

    0x53 与 0x52 是相同的物理 EEPROM 芯片。

    CAT23M01 是一款 128KB EEPROM。 I2C 使用 16 位内部寻址(最大 64KB)、因此芯片使用两个 I2C 地址来访问所有存储器:

    存储器地址 存储器组
    0x52 低 64KB (0x00000 - 0x0FFFF)
    0x53 高 64KB (0x10000 - 0x1FFFF)

    这是大型 EEPROM 的标准 — 而不是扫描异常。

    此致、

    Brennan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好 Brennan、

    我尝试了 I2C_led_blink_interrupt_lld 并且 LED 阵列闪烁正常工作。

    确认之后、我修改了该i2c_led_blink_interrupt_lld.c文件并将 LED 闪烁逻辑替换为 μ I²C 扫描代码(在下面分享)。

    但是、扫描结果仍会在地址上显示相同的器件 0x1C、0x52 和 0x53 、和 未检测到 0x61

    您能检查一下代码或方法是否有任何问题吗?

    谢谢、
    Sai Kiran

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Sai、

    您能分享这个代码吗? 您未在回复中包含任何内容。

    可能的原因:TPIC2810 不确认简单探头
    TPIC2810 LED 控制器使用特定的命令字节: — 0x11 — 对移位寄存器进行读取/写入
    - 0x22 — 负载输出
    - 0x44 — 写入立即

    典型的 I2C 扫描仅发送一个地址(或地址+ 0x00)并检查 ACK。 TPIC2810 可能不会对此做出响应 — 它可能只会 ACK
    何时接收到有效命令序列。

    如果没有代码、您能否确认:

    1.扫描如何探测每个地址?
    -只写探测器(地址+ W 位)?
    -读取探头(地址+ R 位)?
    -写入数据字节(什么字节)?
    2.扫描是通过检查 ACK/NACK 还是通过超时工作?

    当您可以修改代码时、请尝试使用有效的 TPIC2810 读取命令专门探测 0x61:
    1.发送地址 0x61(写入)
    2.发送命令字节 0x11
    3.使用地址 0x61 重新启动(读取)
    4.读取一个字节

    如果这收到响应、但您的通用扫描没有、则 TPIC2810 根本不会确认裸地址探头。

    此致、

    Brennan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、  

    请检查附件中的代码!

    e2e.ti.com/.../I2c_5F00_Bus_5F00_scan.rar

    当您可以修改代码时、请尝试使用有效的 TPIC2810 读取命令专门探测 0x61:
    1.发送地址 0x61(写入)
    2.发送命令字节 0x11
    3.使用地址 0x61 重新启动(读取)
    4.读取一个字节

    可能是、我会验证一次。

    谢谢、

    Sai Kiran

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Sai、

    谢谢、在您尝试使用有效的 TPIC2810 读取命令后、请立即更新我。

    此致、

    Brennan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好 Brennan、

    我已经尝试使用I2C_Transaction而不是I2C_probe()。 目前、TPIC2810 对此做出响应。

    #include
    #include
    #include
    #include “ti_drivers_config.h"</s>“
    #include “ti_drivers_open_close.h"</s>“
    #include “ti_board_open_close.h"</s>“

    /* TPIC2810 I2C 详细信息*/
    #define TPIC2810_ADDR (0x61)
    #define TPIC_CMD_READ (0x11)

    /*使用正确的命令序列检查 TPIC2810 的函数*/
    void TPIC2810_CHECK (void)
      I2C_Transaction 转换;
      uint8_t txBuf[1]
      uint8_t rxBuf[1]
      int32_t 状态;

      /*初始化事务*/
      I2C_Transaction_init (&trans);

      /*要发送的命令*/
      txBuf[0]= TPIC_CMD_READ;

      TRANS.targetAddress = TPIC2810_ADDR;

      /*写入设置*/
      trans.writeBuf = txBuf;
      Trans.writeCount = 1

      /*读取设置*/
      trans.readBuf = rxBuf;
      Trans.ReadCount = 1

      /*执行 I2C 传输(写入+重复启动+读取)*/
      状态= I2C_TRANSFER (gI2cHandle[0]、&trans);

      if (status == SystemP_Success)
      {
        DebugP_LOG(“TPIC2810 在 0x61 中检测到!\r\n“)
        DebugP_LOG(“Received Data:0x%02x\r\n“rxBuf[0]);
      }
      暴露
      {
        DebugP_LOG(“TPIC2810 在 0x61\r\n“处无响应)
      }
    }

    /*主应用程序*/
    void I2C_SCAN_Application (void * args)
      /*打开驱动程序*/
      drivers_open()
      BOARD_DRIVERSOpen ();

      DebugP_LOG(“I2C TPIC2810 检测已启动...\r\n“)

      while (1)
      {
        TPIC2810_CHECK ();

        DebugP_log(“---------------------------------------- \r\n“)

        /*延迟 1 秒*/
        ClockP_SLEEP (1);
      }

      /*闭合驱动程序(从未在循环中到达)*/
      Board_driversClose()
      drivers_close()
    }   

    我知道某些 I2C 器件可能无法确认标准探头序列、在这种情况下、LED 阵列 (TPIC2810) 似乎就是这样的器件。

    感谢您对此提供的宝贵见解和指导。

    此致、
    Sai Kiran

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Sai、

    很高兴我们来到这个问题的底部! 感谢您的耐心。

    此致、

    Brennan