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.

[参考译文] TDA4VH-Q1:TDA4VH-Q1:从摄像头模块刷写 MCU 固件期间[RTOS] I2C 通信问题

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1624881/tda4vh-q1-tda4vh-q1-rtos-i2c-communication-issue-during-mcu-firmware-flashing-from-camera-module

器件型号: TDA4VH-Q1
Thread 中讨论的其他器件: TDA4VH

尊敬的专家:

以下是我们的硬件和软件设置:

硬件:
J784S EVM <--> DS90UB9702 Fusion2 电路板<--> DS90UB971(我们的定制电路板)<-->具有 MCU 的 OX08B40 传感器(8MP @ 30fps、UYVY 格式)

软件:
RTOS SDK 11.00.00.06

我们的摄像头板包含一个 MCU。 我们能够使用 I2C_TRANSACTION () 与此 MCU 正确通信。 我们还验证了传感器流式传输是否正常工作。 MCU 仅用于配置传感器。

然而,当我们试图 将固件刷写到 MCU 中 、我们不断遇到 I2C 故障、这会导致固件刷写失败。

从返回错误状态 I2C_TRANSACTION () 包括等值 –1、–2、 –4、–5。 (每次,故障值可能不同) 。 根据 i2c.h、它们对应于以下错误:

#define I2C_STS_ERR_TIMEOUT (-(int16_t)(1))
#define I2C_STS_ERR_BUS_BUSY (-(int16_t)(2))
#define I2C_STS_ERR_NO_ACK (-(int16_t)(3))
#define I2C_STS_ERR_ARbitration_LOST (-(int16_t)(4))

#define I2C_STS_ERR_ACCESS_ERROR  (-(int16_t)(5))

 

因此、我们观察到以下 I2C 错误:

  • I2C 总线忙错误

  • 仲裁丢失错误

  • 超时错误

  • I2C 总线访问错误

请注意 在给定的时间、我们仅与 MCU 通信 、并且没有发生其他 I2C 设备事务。

在固件刷写期间、我们会以块的形式将固件数据写入 MCU 32 字节+ 2 字节校验和(共 34 个字节) PER 事务。

示例代码片段:


状态= OX08B40_WriteReg (i2cInstId、i2cAddrSensor、0、g_bload_buf、32 + 2 0);
if (status != true)

printf(“%s (%d):OX08B40_WriteReg/OX08B40_ReadReg 在 32 字节中失败、状态=%d\n“、
FUNC、LINE、status);
返回–1;
}

对于一些迭代、传输成功、但 事务随机失败 以及状态值 –1、–3 或–4

 

通过测试:

 
  • 固件刷写过程 15 次(尝试之间下电上电)

  • 系统 1 或 2 次尝试成功

  • 故障率约为 95%

 

为了进一步研究、我们在中尝试了相同的固件刷写过程 这些工作 和 Linux 中的 IT 每次失败率为 0%时都会成功

 

因此、我们希望了解:

    

  • 是什么原因导致的这些 I2C 故障 RTOS 环境

  • 为什么相同的固件刷写过程可以在可靠地运行 但在 RTOS 中不适用

  • 是否已知 I2C 驱动程序限制、时序要求或配置更改 RTOS SDK 11.00.00.06 中需要此用例?

  • 如何克服这个问题?  

请指导我们如何解决此问题。

感谢您帮助调试和解决此问题。

正在等待您的回答。

谢谢&谨致问候

jeyaprakash CK

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

    尊敬的 Jeyaprakash:

    您在 i2c 配置中使用哪种时钟模式?

    您使用的是轮询模式还是中断模式?

    此致、

    Vinit

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

    目前、我们使用的是 轮询模式 对于 I2C 事务、时钟速度配置为 100kHz ()i2cParams.bitRate = I2C_100kHz

    我们还尝试了启用 中断模式 但是我们也在中断模式下观察到了同样的问题。

    下面是我们用于在 I2C 配置中启用中断模式的代码片段:

    I2C_HwAttrs i2c_cfg;
    I2C_Params i2cParams;
    
    /* Get current I2C configuration */
    I2C_socGetInitCfg(i2cInstId, &i2c_cfg);
    
    /* Enable interrupt mode */
    i2c_cfg.enableIntr = true;
    
    
    I2C_socSetInitCfg(i2cInstId, &i2c_cfg);
    
    /* Initialize parameters */
    I2C_Params_init(&i2cParams);
    
    
    i2cParams.transferMode = I2C_MODE_BLOCKING;
    
    i2cParams.bitRate = I2C_100kHz;
    //i2cParams.bitRate = I2C_400kHz;
    
    
    sensorI2cHandle = I2C_open(i2cInstId, &i2cParams);
    
    

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

    尊敬的 Jeyaprakash:

    我对刷写和正常事务有一些疑问、

    优选 i2c 来刷写 MCU 的意图/原因是什么(尽管其速度比其他 MCU 慢)?

    当您与 MCU 执行正常(非刷写)的 I2C 事务时、您通常使用什么大小? 34 字节的单次事务是否成功?

    在固件刷写期间、第一个 34 字节的事务是否总是成功、还是从一开始就随机失败?

    请在固件刷写期间使用逻辑分析仪捕获 I2C 事务、以更好地进行调试。

    此致、

    Vinit

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

    尊敬的 Vinit

     使用 I2C 进行 MCU 刷写的原因

    使用 I2C 刷写 MCU 的主要原因与有关 摄像头模块中提供的硬件接口 。 在大多数摄像头模块平台中 FPC/MIPI 连接器(通常为 15 引脚或 22 引脚标准) 已经公开了 高速 I2C 线路以及 MIPI CSI 数据通道 以进行传感器控制。

    由于连接器上已提供 I2C 接口并已连接到 MCU、因此我们更倾向于使用该现有的接口进行固件刷写。 这样就避免了对的需求 其他专用刷写接口(如 UART、SPI...) 、这将需要在模块上更改额外的引脚、布线和硬件。

    2.正常(非刷写)I2C 事务

    为了与 MCU 进行正常的 I2C 通信、事务能够可靠地进行。

    我们已经验证过这一点 34 字节单个 I2C 事务成功 正常通信期间的通信中断。 在除固件刷写之外的某些地方、我们 也使用 48 字节传输、这也是成功的。

    3.固件刷新过程中的行为

    在固件刷写期间、出现故障 在第一个事务时不会始终发生

    指定 大多数情况 、前几个事务成功、出现故障 在刷写过程中的某个位置随机分配

    指定 极少数情况 、则可能会发生故障 提取第一个事务 但这种情况并不常见。

    出现故障 随机 而不是发生在固件传输中的固定位置。

    为了进一步调试该问题、我们还提供了一个示例 减小传输大小。  数据有效载荷: 8 字节和  校验和: 2 字节(总共 10 字节)

    即使传输大小减小、也可以使用 闪烁仍然随机失败 发送电子邮件。

    一个重要的观察结果是 相同的固件刷写逻辑可在 Linux 中可靠运行 、带有 0%故障率

    不过、在中 驱动程序 、刷新过程随机失败。 完整的固件刷写过程大约需要花费一些时间 2-3 分钟

    这使我们想知道是否可以:

    a. Linux 和 RTOS I2C 驱动器之间的时序差异?

    不限 RTOS 调度行为 I2C 访问时序有何影响?  

    引脚 总线仲裁或总线访问时序差异?

    我已经从硬件团队请求逻辑分析仪,这将需要一些时间 来调试.

    在此期间、请您指导我们:

    不限 RTOS 中用于大型顺序传输的建议 I2C 配置或驱动程序设置

    是否 总线时序、任务调度或中断延迟 I2C 通信的持续时间

    不限 建议用于识别连续传输期间故障的调试方法

    谢谢  

    jeyaprakash C K

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

    尊敬的 Jeyaprakash:

    好的、我理解。

    在等待硬件团队的 Logic Analyzer 时、

    让我们将刷写任务置于最高优先级(如果它还不是最高优先级)、以 减少 RTOS 调度干扰。

    此外、在事务之间延迟一些、以查看 MCU 在刷写时是否需要更多的处理时间。

    此致、

    Vinit

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

     

    尊敬的 Vinit:

    当我使用创建任务TaskP_create()时、程序将显示为 在任务创建本身停止 、并且无法从任务函数中看到任何打印件。

    代码片段

     

    TaskP_Params params;
    TaskP_Params_init(&params);
    TaskP_Handle writeTask;
    
    params.priority = 15;      // highest priority
    params.stacksize = 8192;
    
    params.arg0 = (void *)arr;
    params.arg1 = NULL;
    
    printf("Before task creation\n");
    
    writeTask = TaskP_create(flashtask, &params);
    
    printf("After task creation\n");

    任务函数:

    void flashtask(void *arg0, void *arg1)
    {
        uint32_t *arr = (uint32_t *)arg0;
        uint8_t count = 0;
    
        printf("Started flashtask\n");
    
        while(1)
        {
            TaskP_sleep(500);
            printf("inside flashtask function\n");
            //Logic for flashing
    } }

    观察到的行为

    • "Before task creation"输出电压

      "After task creation"未打印  

      "Started flashtask"也不打印

      它似乎是这样 停止内部 TaskP_create()

      代码在内部执行 Sensor RTOS 驱动程序

    问题

    1.  您能指导我们如何正确地 将闪烁的任务放在最高优先级. 有什么我们错过了吗?

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

    尊敬的 Jeyaprakash:

    我怀疑没有提供堆栈缓冲区指针。

    但是、我不建议您使用这种方法、而是提供一种简单的方法、

    只需使用这些 API、

    taskP_handle currentTask = taskp_self (); //获取当前任务的句柄

    taskP_setPrio (taskP_handle handle、uint32_t priority)//在此处使用上述 API 中的该句柄、以优先级设置当前任务的优先级。

    要提高当前任务优先级、它比以前的方法要简单得多。

    如果您在这里遇到任何错误、请告诉我。

    此致、

    Vinit

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

    尊敬的 Vinit:

    感谢您的建议。

    我们尝试了您提高当前任务优先级的方法、而不是创建新任务。 我们在调用固件刷写函数之前将当前任务优先级更改为最高值、但问题仍然存在。

    即使在提高任务优先级后、固件刷写也不会成功。 我们仍然看到与 I2C 相关的错误

    总线忙错误、i2c 仲裁丢失错误、无确认错误。  

    以下是我们当前使用的代码片段:


    TaskP_Handle currentTask;
    int ret1;
    uint32_t 优先级= 15;

    currentTask = taskp_self ();
    if (currentTask == NULL)

    printf(“TaskP_self 返回 NULL\n“);
    返回–1;
    }

    /*暂时提高优先级*/
    TaskP_setPrio (currentTask、priority);
    printf(“******* 当前任务优先级更改为%u********** \n“,优先级);
    appLogWaitMsecs(5);


    if (mcu_FW_update (i2cAddrSensor、i2cInstId、NULL)< 0){
    printf(“更新固件\n“错误);
    返回–1;
    }

    有什么我们遗漏的吗? 或者、 这些错误是否表示另一个访问同一 I2C 总线的任务/主器件发生争用?   

    请指导我们。

    谢谢  

    jeyaprakash C K

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

    尊敬的 Jeyaprakash:

    优先级更改没有解决问题、因此这说明问题主要不是 RTOS 调度。

     这些错误是否表示另一个访问同一 I2C 总线的任务/主任务发生争用?   [/报价]

    在固件刷写期间、同一总线上是否发生了任何其他 I2C 活动?

    此外、正如我前面提到的、您是否尝试过在刷写时的事务之间增加延迟?

    如果所有这些都不起作用、那么在我们访问逻辑分析仪后、我们可能就可以清楚地了解这个问题。

    此致、

    Vinit

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

    你好、vinit

    是的、我已经尝试在固件刷写期间在 I²C μ s 事务之间引入延迟、但这并没有解决问题。 此外,除了与 MCU 通信之外,我们不会执行任何通信( i2c 活动)。

    我们观察到了与电缆长度相关的重要情况:

    最初、我们使用了 10m FPD-Link IV 电缆 。 使用此设置时、只能成功刷写固件 15 次迭代中的 1 次 (在极少数情况下,15 种中偶尔会有 2 种)。

    然后、我们用较短的尺寸进行了测试 80cm 电缆 。 在这种情况下、 20 次迭代中有 17 次成功

    接下来、我们尝试了一个 3m 电缆 、其中成功率是多少 10 次迭代中的 5 次 (~50%)

    这清楚地表明电缆长度和闪存可靠性之间有很强的相关性。

    然而、我们在所有电缆长度 (80cm、3m 和 10m) 上验证了视频/数据流、并且没有观察到问题。 问题具体发生在期间 固件通过 I²C μ s 刷写到 MCU 中

    对于 10m 电缆外壳,我们使用逻辑分析仪探测了进入模块板上 MCU 的 I²C 线。 从跟踪可以看出、在失败前的最后一个事务中:

         供电 发送 ACK 在总线上、

          但平台报告 “未收到 ACK “ 事务失败。

    我们随附了逻辑分析仪捕获结果以供参考。

    请您帮助澄清一下:

    • 为什么总线上显示 ACK、但平台未检测到该 ACK?
    • 在此设置 (RTOS) 中、用于实现可靠的 μ I²C 通信的最大建议电缆长度是多少?
    • 您是否在更长的电缆上执行了诸如连续/虚拟 I²C 写入之类的应力测试,特别是在 RTOS 中?
    • 您是否在使用较长电缆的 RTOS 环境中评估了 I²C Ω 总线在高事务负载(泛洪)下的行为?

    此外、您能否提出克服这一问题的可行方法?

    谢谢&谨致问候

    Jeyaprakash CK

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

    尊敬的 Jeyaprakash:

    优秀的诊断工作! 您的逻辑分析仪结果清楚地表明、这是 FPD-Link 长电缆上的信号完整性问题、而不是 RTOS 软件问题。

    MCU 发送 ACK 但 TDA4VH 未检测到它这一事实表明 10m 电缆上存在信号衰减和时序问题。

    在我们研究这一点时、我希望您尝试 增加事务超时。

    请告诉我、在不同电缆长度条件下、它对成功率有何影响。

    此致、

    Vinit

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

    你好、vinit

    感谢您的快速答复。

    在较长的电缆长度 (~10m) 时、我最初尝试将 I2C 事务超时设置为 5 秒:

    i2cTransaction.timeout = 5000;

    但是、即使超时增加、事务仍然间歇性失败。 这似乎更有可能是由于较长电缆上的信号完整性下降、而不是纯时序不匹配导致的。

    作为一个下一步,正如你说的,我将应用相同的 5 秒(这是巨大的。.) 在较短的电缆上超时(当前以 250ms 的超时运行)并观察它是否提高了可靠性。 这应该有助于确定时序是否在故障中起着任何次要作用。 我们还可以验证这是否完全消除了较短电缆上的故障。

    调查完成后、请在此处更新。

    谢谢、此致

    jeyaprakash C K

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

    尊敬的 Jeyaprakash:

    作为下一步,正如你所说,我将应用相同的 5 秒(这是巨大的。) 在较短的电缆上超时(当前以 250ms 的超时运行)并观察它是否提高了可靠性。 这应该有助于确定时序是否在故障中起着任何次要作用。 [/报价]

    是的、请告诉我们您获得了什么。

    调查完成后、请在此处更新。

    没问题。 预计会有一些延迟、因为我们将在漫长的周末进行。 我们会在星期一回来的。

    感谢您的 耐心。

    此致、

    Vinit

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

    你好、vinit

    我也尝试增加较短电缆上的事务超时,但这并没有改变行为 — 同样的观察结果仍然存在。  这表明时序可能不是导致故障的因素

    谢谢、此致

    jeyaprakash C K

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

    尊敬的 Jeyaprakash:

    但是、我们验证了所有电缆长度 (80 cm、3 m 和 10 m) 的视频/数据流、没有发现任何问题。 问题具体发生在期间 固件通过 I²C μ s 刷写到 MCU 中 .

    这里、您说您传输了视频/数据流、是仅通过 I2C 传输的吗?

    除此之外、您捕获的信号是在 SOC 侧还是远程 MCU 侧?

    另外、在这张图片中

    为什么两个 ACK 的尺寸不同?

    此致、

    Vinit

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

    你好、vinit

    i)  

    否、视频/数据流不会通过 I²C μ s 传输。 它通过传输 MIPI 数据通道 (用于视频流的高速差分线路)。

    我的意思是:

    电缆长度越长、MIPI 视频流就能正常工作。  
    但是、对于固件刷写、我们使用 μ I²C 线路 (SDA/SCL)。
    问题在于、使用较长电缆时 I²C Ω 通信会失败。

    (二)

    我捕获了上的信号 摄像头模块侧 直接探测 I²C Ω 线路并使用逻辑分析仪进行分析。

    我们不能  探测 SoC(平台)侧 I n 该项 t 因此、当前观察是 从摄像机模块结束

    (三)

    指定 I2C 、ACK 定义为接收器拉动 SDA 线路低电平(逻辑 0)

    对于事务 0x00 + ACK:


    理想情况下、SDA 应保持完全低电平、并且也应在 ACK 位期间保持。
    您看到的小尖峰可能是测量噪声或捕获工具产生的干扰、而不是有效的逻辑转换。 您也可以看到它完全处于低电平

    对于 0xAB + ACK:
    二进制表示:

    1 0  1 0       1 0 1  + ACK (0)

    该波形看起来正确、并且与预期的 I²C 行为一致。 即使它已经 sended ack ,在平台侧,它显示为 NACK。 正如您所说的、这可能是由于信号衰减所致!!!

    谢谢&谨致问候

    jeyaprakash CK

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

    尊敬的 Jeyaprakash:

    您使用的所有模块上的总线电容是多少?


    除此之外、TI 建议使用长度小于 1m 的电缆进行 I2C 通信。

    [报价 userid=“658497" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1624881/tda4vh-q1-tda4vh-q1-rtos-i2c-communication-issue-during-mcu-firmware-flashing-from-camera-module 硬件:
    J784S EVM <--> DS90UB9702 Fusion2 电路板<--> DS90UB971(我们的定制电路板)<-->具有 MCU 的 OX08B40 传感器(8MP @ 30fps、UYVY 格式)[/报价]

    这些板位于同一条 I2C 总线上?

    此外、如果可能、您能否直接删除模块之间的那些内容、然后直接尝试将固件刷写到 MCU 中? 因为同一条路径上的更多模块可能会导致信号降级。

    如果模块的总总线电容很高、您 应该 尝试使用总线扩展器来使此固件刷写工作。

    此致、

    Vinit

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

    你好、vinit  

    i) 我们 在我们的适配器板和解串器 DS90UB9702 电路板中使用 TI 的串行器 DS90UB971。 根据串行器数据表、 支持的 I²C μ F 总线容性负载约为 400 pF。 我们正在此指定限值内运行、并且尚未修改此约束。

    ii) 我想在这里澄清 I²C 拓扑。 在传感器和串行器之间、有直接的 I²C 线。 但是、串行器和解串器之间的通信通过 FPD-Link 接口进行、其中 I²C 事务封装到串行化数据中并通过电缆传输。 在解串器中、这些数据包经过解串、并再次以 I²C 的形式呈现在平台上。

    因此、从技术上讲、串行器和解串器之间没有连续的物理 I²C Ω 线;通信通过 FPD-Link 进行封包化

    我们的固件刷写路径是:
    Platform I²C→Deserializer→(FPD-Link、无直接 I²C)→Serializer→I²C→MCU/摄像头模块

    iii)  在此设置中无法将 MCU 直接连接到平台(用于固件刷写)。

    iv) 如前所述、我们使用 TI 串行器和解串器 、并在其数据表中指定的总线电容限制范围内运行。

    注意: 采用相同的设置(长电缆,串行器,解串器和相同的传感器)f 在 Linux 中、irmware 刷新成功 但在 RTOS 中失败。 因此、仅依靠总线电容可能不是根本原因、因为它在两种环境之间保持不变。 Linux 和 RTOS 之间的行为必然会有一些差异、导致出现这个问题。

    谢谢、此致

    jeyaprakash C K

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

    尊敬的 Jeyaprakash:

    感谢您的详细说明。

    现在您有了逻辑分析仪、您可以在使用 Linux 进行固件刷写时捕获事务吗?

    使用 RTOS 时、I2C 使用了 100KHz 比特率、类似地、使用 Linux 时的比特率是多少?

    此致、

    Vinit

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

    您好、vinit、

    在从 Linux 执行固件刷写时、我可以尝试使用逻辑分析仪捕获 μ I²C 事务。 但是、可能需要一些时间、因为我需要再次向硬件请求。

    尽管如此、我不确定在 Linux 端捕获 I²C 事务还能获得多少额外的见解、因为固件刷写始终是成功的。  

    根据我们迄今为止的分析:

    在 RTOS 中 ( B7 实现 )、从串行器到摄像头模块的默认 μ I²C 时钟被配置为 100kHz。 这通过探测连接到摄像头模块的串行器 I²C 线路 (使用 DSO 进行检查)进行了验证。
    在 Linux 设置中、串行器和摄像头模块之间的 I²C μ s 时钟以大约 400kHz(快速模式)的频率运行。
    我们尝试修改 RTOS 配置、以使用 400kHz、但即使在 RTOS 中以这种更高的速度、固件刷写问题也会持续存在。

    以下是 RTOS 中用于将串行器 I²C BUS 设置为 400kHz 的寄存器配置:

    #if defined(B7_实现)
    静态 int32_t configure_serial (uint8_t Chid、Iss Sensor_Module ModuleInfo、uint8_t serAddr)

    int32_t 状态=–1;

    静态 I2cParams ub971InitScript[]={
    {0x4B、0x02、0x00}、/*禁用 BC 交替模式自动检测*/
    {0x49、0x06、0x00}、/*减少 971 BC-RX 上的链路检测计时器*/
    {0x0A、0x12、0x00}、/*将 I2C 总线看门狗计时器速度提高至~50us */
    {0x0B、0x13、0x00}、/*将速度配置为快速模式 400KHZ */
    {0x0C、0x26、0x00}、/*将速度配置为快速模式 400KHZ */
    {0xFFFF、0x00、0x00}/*结束脚本*/
    };

    就此、我们观察到的一个关键差异是 μ I²C 时钟速度变化:

    RTOS→100kHz(默认值)
    Linux→400kHz(默认值)

    在 Linux 中,在串行器驱动程序中,默认设置为快速模式 (400KHZ )。

    static int ub953_i2c_master_init (struct ub953_data *priv)

    /* i2c 快速模式*/
    u32 ref = 26250000;
    u32 SCL_HIGH = 915;/* ns *//标称延迟
    u32 SCL_LOW = 1641;/* ns *//标称延迟
    内部 ret;

    scl_high = div64_u64 (u64) scl_high * ref、1000000000)- 5;
    scl_low = div64_u64 (u64) scl_low * ref、1000000000)- 5;

    RET = ub953_write (priv、UB953_REG_SCL_HIGH_TIME、SCL_HIGH);
    IF (RET)
    返回 ret;

    RET = ub953_write (priv、UB953_REG_SCL_LOW_TIME、SCL_LOW);
    IF (RET)
    返回 ret;

    返回 0;
    }

     

    但是、即使在 RTOS 中将时钟速度调整到 400kHz 后、该问题仍然存在。

    鉴于固件刷写过程发生在串行器/解串器路径 I 上 Linux 和 RTOS 之间的其他配置差异可能导致了该问题。 这些可能包括类似的东西..:

    串行器 I²C 时序参数  
    解串器侧 I²C 转发  
    链路稳定性/锁定时间
    反向通道(控制通道)配置
    在 Linux 驱动程序中执行的任何其他初始化序列

    您能否帮助您(或您的团队)分析 Linux 和 RTOS 的关键寄存器配置和初始化差异、特别是在这两方面:

    串行器侧
    解串器侧

    这将有助于确定 I²C 的任何关键设置、尤其是影响用于固件刷写的 μ C 控制路径的设置。

    在此基础上、我们可以缩小根本原因的范围并努力解决问题。

    IAM 连接我使用的 Linux 解串器和串行器驱动程序。  

    e2e.ti.com/.../ds90ub953.c

    e2e.ti.com/.../1145.ds90ub960.c

    e2e.ti.com/.../ds90ub953.h

    谢谢、此致

    Jeya Prakash CK  

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

    尊敬的 Jeyaprakash:

    只需确认 Linux 中的默认代码为 400kHz、您还检查了 100KHz(我可以在您提供的代码文件中看到)、在这两种情况下都能正常工作。

    在 另一侧使用 RTOS ,它不能同时使用 100KHz 和 400KHz。

    我是正确的还是缺少某些内容?

    此外、您是否确定此设置的所有组件上的 i2c 都在您设置的相同时钟速率 (100KHz/400kHz) 下工作?

    此致、

    Vinit

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

    你好、vinit

    i) 在 Linux 中、i2c 刷写 在 100kHz 和 400kHz 下运行。

    ii) 在 RTOS 中、i2c 刷写在 100kHz 或 400kHz 下无法正常工作。

    iii) 在 RTOS 中、我们验证了整个路径上的 I2C 时钟配置:
     
    Platform→Deserializer
    串行器→传感器

    配置的时钟速率 (100kHz/400kHz) 应用正确。 我们还使用 DSO 测量确认了这一点。

    此外、在故障场景中、我们观察到以下情况:

    在平台→解串器 I2C 线路上、时钟 (SCL_PLATFORM) 保持低电平。
    在此点之后没有时钟活动。
    这似乎是时钟延展、可能是由解串器将时钟线保持为低电平引起的。

    我们附上了一张来自 DSO 的参考波形图像,用于此观察。



    请确认是否:

    解串器可能有意保持时钟(例如,由于内部处理,超时或错误情况)?
    RTOS 上有任何与 Linux 不同的其他时序/配置要求?

    此致、

    jeyaprakash CK

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

    尊敬的 Jeyaprakash:

    我们正在查看您的最后一封邮件。

    i2cTransaction.timeout = 5000;

    同时,我可以从先前的消息中看到,您使用的 ITC 事务超时为 5000 ,默认的 SDK 示例使用 10000 ,您可以尝试使用 10000 作为超时或将其增加到 10000 以上。 要求您执行此操作的原因是、如果处理时间是时钟拉伸背后的问题、那么这应该可以解决。

    感谢您耐心等待、

    Vinit