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.

[参考译文] MSPM0G1507:在快速模式 (400kHz) 下通信时、控制器侧会将数据移位 1 个字节。

Guru**** 2872500 points

Other Parts Discussed in Thread: SYSCONFIG, MSPM0G1507, MSPM0G3507

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1631775/mspm0g1507-when-communicating-in-fast-mode-400khz-the-controller-side-shifts-the-data-by-1-byte

部件号: MSPM0G1507
Thread 中讨论的其他器件: SysconfigMSPM0G3507

尊敬的专家:

在快速模式 (400kHz) 下进行通信时、控制器侧会将数据移位 1 个字节。 在控制器和目标上均启用了时钟延展、但问题仍然出现。

我使用以下软件 (mspm0_sdk_2_10_00_04)。
  • I2C_CONTROLLER_RW_multibyte_fifo_interrupts
  • I2C_TARGET_RW_multibyte_fifo_interrupts
  • 我只将 SysConfig 的控制器侧设置为 400kHz、并在两侧打开/关闭时钟延展功能、将编译器优化级别更改为 0。 我没有修改.c 文件。  

Q1:是否有我可能忽略的设置?
问题 2:此外、除了使用 DMA 外、是否有针对这种情况的有效对策?

总之、目标侧的变速器似乎没有跟上。 当我查看波形时、目标侧发送第一个字节的虚拟数据。 如果在目标侧启用了时钟延展、则会将 0x08 作为虚拟数据发送;如果禁用、则会发送 0x00。 从第二个字节开始、数据按 0x00、0x01 等顺序发送 目标侧的接收缓冲区 (gRxPacket) 正在正确接收、发送缓冲区 (gTxPacket) 也正在正确复制数据。 由于我无法直接检查 TXFIFO、因此我查看了 STXDATA、0x0F 已存储。

此致、
O、H

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

    尊敬的专家:

    是否有任何更新?

    此致、
    正常

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

    嗨、O.H

    请帮助澄清以下几项:

    1.对于 MSPM0G1507、用作 I2C 控制器或目标?

    2、数据写入或读取时出现问题?

    3.您能在这里分享一个可以重现此问题的简单工程或 sysconfig 文件吗?

    4.如果你用 Saleae 捕捉波形,你也可以把它放在这里

    此致

    Gary

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

    您好、 Gary、

    感谢您的答复。

    [quote userid=“319723" url="“ url="~“~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1631775/mspm0g1507-when-communicating-in-fast-mode-400khz-the-controller-side-shifts-the-data-by-1-byte/6301753 对于 MSPM0G1507、用作 I2C 控制器或目标?

    1:在客户主板上、G1507 是目标。

    [quote userid=“319723" url="“ url="~“~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1631775/mspm0g1507-when-communicating-in-fast-mode-400khz-the-controller-side-shifts-the-data-by-1-byte/6301753 数据写入或读取期间出现问题?

    2:这是在 G1507 的传输过程中。 当目标的时钟延展被禁用时、似乎会发生这种情况。

    [quote userid=“319723" url="“ url="~“~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1631775/mspm0g1507-when-communicating-in-fast-mode-400khz-the-controller-side-shifts-the-data-by-1-byte/6301753 您能给我分享一个可以重现此问题或在此处生成 SysConfig 文件的简单工程吗?
    3:在我的环境中使用两个 G3507EVM 时、我会分享该项目。
    [quote userid=“319723" url="“ url="~“~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1631775/mspm0g1507-when-communicating-in-fast-mode-400khz-the-controller-side-shifts-the-data-by-1-byte/6301753 如果您使用 Saleae 捕获波形、您也可以将其放在此处

    4:这是在客户主板上使用 G1507 时的波形。 使用的示例工程是相同的。 (由于它在目标端,我刚刚禁用了 SysConfig 的时钟延展。)
    【写入】
    【读取】
    此致、
    正常

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    禁用目标的时钟延展时似乎会发生这种情况

    你确定吗? a、如下所述

    f 在目标端启用时钟延展、0x08 作为虚拟数据发送;

    剂量 0x08 是预期的正确数据?

    还有一个问题是、是否将频率更改为 100k、问题是否发生剂量?

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

    您好、Gary、

    剂量 0x08 是预期的正确数据?

    编号  

    还有一个问题是是否将频率更改为 100k、是否会发生问题?

    当频率超过 250kHz 时、就会发生这种情况。

    此致、
    正常

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

    您好、 Gary、

    抱歉。  由于解释不充分、我将重写包括重新审查结果在内的说明。

    EVM 环境中的验证结果会使事情变得复杂、但我将重申我们的目的。 我们的目的是以 400kHz 的频率与目标器件时钟延展进行通信。
    我的客户以 400kHz 的频率与 G1507 进行通信、同时时钟会延长。 控制器执行 Write→Read。 G1507 由控制器写入一次、然后按原样返回写入的数据、以响应控制器的读取请求。 (这正是“i2c_target_rw_multibyte_fifo_interrupts_LP_MSPM0G3507_nortos_ticlang"的“的操作的操作。) 问题在于返回到控制器的数据被 1 个字节移动。 使用 EVM 可以看到相同的结果。
    我们的问题:请告诉我们如何处理这种数据被 1 字节移动的现象?

    在客户环境中、G1507 是目标、另一个 CPU 是控制器。
    在我的环境中、一个 G3507EVM 是目标、另一个 G3507EVM 是控制器。
    当目标器件的时钟延展关闭且通信频率为 400kHz 时:
    客户环境中的预期值为 0xFE ->0xDC、但当控制器读取它时、它变为 0x00 ->0xFE。
    在我的环境中、预期值为 0x00->0x01、但当控制器读取它时、它变为 0x00->0x00。

    在我的 EVM 环境中进行重新实验后、我发现存在差异、具体取决于目标的优化级别。
    当目标的时钟延展开启且通信频率为 250kHz 或更高时:
    如果目标的优化级别为 0、则会出现问题。 如果目标的优化级别为 2、则不会出现问题。  
    下图显示了在控制器端监控 GRX/TxPacket 的结果。
    下图显示了监控目标侧 GRX/TxPacket 的结果、这一结果始终相同。
    附加了其他模式以供参考。
    此致、
    正常

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

    嗨、O.H

    对于该问题、是由于 I2C 时钟速度过快、无法为 I2C 从器件保留足够的时间将数据从 TX 缓冲器移动到 TX FIFO 而发生的。

    测试完成后、将数据从 TX 缓冲器移动到 TX FIFO 需要大约 8us、但 400k 时钟的一个周期仅为 2.5us、这不足以进行数据传输、因此第一个字节将始终为用于数据移动的 0x00。 为解决该问题、我可以帮助修改在接收到的数据完成停止中断后移动数据的代码、并跳过开始中断中的 TX FIFO 清除。 您可以参考的代码  

    e2e.ti.com/.../4442.i2c_5F00_target_5F00_rw_5F00_multibyte_5F00_fifo_5F00_interrupts_5F00_LP_5F00_MSPM0G3507_5F00_nortos_5F00_ticlang.zip

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

    您好、 Gary、

    感谢您的支持。
    [引述 userid=“319723" url="“ url="~“~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1631775/mspm0g1507-when-communicating-in-fast-mode-400khz-the-controller-side-shifts-the-data-by-1-byte/6305135

    为解决该问题、我可以帮助修改在接收到的数据完成停止中断后移动数据的代码、并跳过开始中断中的 TX FIFO 清除。 您可以参考的代码  

    4442.i2c_target_rw_multibyte_fifo_interrupts_LP_MSPM0G3507_nortos_ticlang.zip

    [/报价]

    我已经检查了您提供的项目的运行情况。 我确认目标侧的时钟延展已关闭、并在不进行任何更改的情况下使用。

    因此、当设置 Optimization level=2(或 1)时、在 400kHz 处没有问题。 但是、设置优化级别=0 时、如果频率超过 355.5kHz、就会出现问题。 (高达 320kHz 时无问题)

    问:是否有一种以 400kHz 的频率进行通信的方法、在目标端关闭时钟且优化级别为 0? 是否必须设置 Optimization Level=2(或 1)?

    此致、
    正常

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我确认目标端的时钟延展已关闭、并在不进行任何更改的情况下使用它。

    您做任何更改的意思是什么?  

    演示效果很好  以 400kHz 的频率与目标器件时钟延展进行通信。 您可以看到 Saleae 捕获的波形。

    e2e.ti.com/.../7120.Session-0.sal

    数据在 400kHz 时有任何移位。

    我还尝试将项目的优化设置为 0、这样就可以正常工作。

    您是否尝试过我分享给您的代码?

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

    您好、Gary、

    感谢您的答复。

    您做任何更改的意思是什么?  [/报价]

    我只更改了优化级别。 我测试了 0、1 和 2 级。 在我的环境中、1 字节偏移仅发生在级别 0。 我通过 CCS 中的波形和变量确认了这一点。

    她是我的客户反馈。

    [引述 userid=“319723" url="“ url="~“~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1631775/mspm0g1507-when-communicating-in-fast-mode-400khz-the-controller-side-shifts-the-data-by-1-byte/6305135

    对于该问题、是由于 I2C 时钟速度过快、无法为 I2C 从器件保留足够的时间将数据从 TX 缓冲器移动到 TX FIFO 而发生的。

    测试完成后、将数据从 TX 缓冲器移动到 TX FIFO 需要大约 8us、但 400k 时钟的一个周期仅为 2.5us、这不足以进行数据传输、因此第一个字节将始终为用于数据移动的 0x00。

    [/报价]

    问题 3:能否用计时示意图来解释?
    我认为关于 20µs 仍然有一些裕量、因为从启动到从器件地址阶段有 9 个时钟周期。

    要解决此问题、我可以帮助修改在接收到的数据完成停止中断后移动数据的代码、并跳过启动中断中的 TX FIFO 刷新。

    我还考虑了停止结束、但因为它在重启模式下不起作用(重复启动,不停止)。 因此、我想考虑一种在前一个接收 RxFIFO 触发器(阈值= 1)时提前填充 TXFIFO 的方法。
    Q4:您能否告诉我,这种方法是否有任何问题,或者是否有推荐的方法?

    此致、
    正常

    [/quote]
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我只更改了优化级别。 我测试了 0、1 和 2 级。 在我的环境中、1 字节偏移仅发生在级别 0。 我从 CCS 中的波形和变量都确认了这一点。

    我之前分享的剂量客户使用代码?

    我认为 20µs 还有一些裕量、因为从启动到从器件地址阶段有 9 个时钟周期

    不可以、如果在地址位完全接收之后归档、则启动中断意味着数据移动只剩下两个时钟(大约 5us)。

    q4:您能否告诉我这种方法是否有任何问题、或者是否有推荐的方法?

    如果处于重复启动条件、您可以在触发重复启动之前移动数据。  

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

    您好、 Gary、

    很抱歉晚才回复。

    由于这一主题在我这边不能正常运作、我想继续下面这一主题的讨论。
    (+) MSPM0G1507:在快速模式 (400kHz) 下进行通信时、控制器侧会在重复启动操作中将数据移动 1 个字节 — 基于 Arm 的微控制器论坛 — 基于 Arm 的微控制器 — TI E2E 支持论坛

    我的客户确认、 您建议的代码(其中数据在 STOP 中断中更新)工作正常、不会导致任何问题。 下一个问题与重复启动操作有关、该操作不会发生 STOP。

    此致、
    正常

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

    好的、将首先关闭该线程