• 状态 Resolved
  • 已锁定 已锁定
  • 回复 13 回复
  • 订户 0 订户
  • 视图 391 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] MSP430FR5962：I2C 时钟保持低电平

admin
Guru**** 2383270 points
Other Parts Discussed in Thread: MSP430FR5962, MSP430FR5949
请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/855641/msp430fr5962-i2c-clock-held-low

器件型号：MSP430FR5962
主题中讨论的其他器件： MSP430FR5949

我通过 I2C 总线连接了 MSP430FR5949和 MSP430FR5962、总线上没有其他单元和上拉电阻。

I2C 链路配置为多主器件、在本例中、MSP430FR5949充当主器件、MSP430FR5962充当从器件接收器。
我看到的问题是、接收器随机保持时钟低电平。 然后由时钟低电平超时和外设复位根据建议执行此操作。
这种情况的时间似乎是随机的、难以衡量、但大约每10万条消息中有1条消息这样失败。
当观察到故障时、它始终位于字节的第7位之后、但字节位置显示为随机。
这种情况看起来好像 UCBnRXBUF 寄存器没有被读取、并且由于接收溢出条件、外设时钟被拉伸。
实际上、如果我故意引入随机不读取 UCBnRXBUF、我会观察到同样的症状。

但是、我确信、在正常情况下发生这种情况时、我已读取并缓冲(通过外部回调函数)接收到的数据、因为我可以在调试器中捕获此数据并观察我的缓冲数据。

此应用程序有多个其他中断处于活动状态、因此在处理任何单个中断时会有一些可变延迟、但其长度与时钟低电平超时无关。

我在中断中添加了一些 GPIO 引脚切换、以观察接收器中的事件序列、并可以看到检测到开始中断、 许多接收中断、包括在第7位挂起的中断之前读取字节的中断、因此我确信我已经读取了上一个接收字节的 UCBnRXBUF 寄存器。

我只能想象会有一些时序或中断交互导致这种情况。
那么、我的问题是：这个操作是否有任何已知问题、如果没有、详细的情况是、触发接收器在接收到第7位数据后进入时钟扩展的确切条件是什么？

很抱歉、由于重新使用 I2C 中断代码、它有点乱、但您得到了一般的想法。
如果这个请求没有得到任何答案、我将不得不尝试用更简单的代码重现问题、但这不是我在项目中预算的时间。

示例捕捉显示了初始写入(CH7上有中断处理程序)、后跟2个成功的 Rx 字节(CH7上有中断处理程序)、后跟第3个数据字节的7位、这会导致时钟低电平、直到随后被处理。 如果我已经读取前2个数据字节的 UCBnRXBUF、为什么第三个字节被保持？ 

//##########################################################################################################################
///@fn void USCI_B0_ISR (void)
//@param[in] <无>
///@返回 <无>
//@请参阅说明 ISR、了解逻辑 I2C 通道0上的 eUSCIB0
//@警告 用途：USCI_B0
//##############################################################################################################
#pragma vector = USCI_B0_vector
_interrupt_ void I2C_USCI_B0_ISR (void)
｛
uint8数据字节；

/*推断中断源*/
开关(_偶数_IN_RANGE (UCB0IV、USCI_I2C_UCBIT9IFG))
｛
USCI_NONE 案例：
中断；

案例 USCI_I2C_UCALIFG：//*仲裁丢失中断*
开关(CurrentConfig[I2C_CHAN_0].IntState)
｛

案例 I2C_INT_State_MA_TX：
/*发送结果*/
CurrentConfig[I2C_CHAN_0].TxResult = I2C_EOM_RESULT_FAIL_TRICT;
CurrentConfig[I2C_CHAN_0].IntState = I2C_INT_State_Idle；
中断；

案例 I2C_INT_State_MA_RX：
/*发送结果*/
CurrentConfig[I2C_CHAN_0].RxResult = I2C_EOM_RESULT_FAIL_TRENTRIC；
CurrentConfig[I2C_CHAN_0].IntState = I2C_INT_State_Idle；
中断；

案例 I2C_INT_State_SL_TX：
/*意外操作*/
CurrentConfig[I2C_CHAN_0].TxResult = I2C_EOM_RESULT_UNKNOWN；
CurrentConfig[I2C_CHAN_0].IntState = I2C_INT_State_Idle；
中断；

案例 I2C_INT_State_SL_RX：
/*意外操作*/
CurrentConfig[I2C_CHAN_0].RxResult = I2C_EOM_RESULT_UNKNOWN；
CurrentConfig[I2C_CHAN_0].IntState = I2C_INT_State_Idle；
中断；

默认值：
/*无事可做*/
中断；

｝ /*结束开关(CurrentConfig[I2C_CHAN_0].IntState)*/
中断；

案例 USCI_I2C_UCNACKIFG：//*未接收到 ACK (仅限主器件)*/
开关(CurrentConfig[I2C_CHAN_0].IntState)
｛
案例 I2C_INT_State_MA_TX：
/*生成停止和终止*/
UCB0CTLW0 |= UCTXSTP；/*生成 STOP */
CurrentConfig[I2C_CHAN_0].TxResult = I2C_EOM_RESULT_NACK；
CurrentConfig[I2C_CHAN_0].IntState = I2C_INT_State_Idle；
中断；

案例 I2C_INT_State_MA_RX：
/*生成停止和终止*/
UCB0CTLW0 |= UCTXSTP；/*生成 STOP */
CurrentConfig[I2C_CHAN_0].RxResult = I2C_EOM_RESULT_NACK；
CurrentConfig[I2C_CHAN_0].IntState = I2C_INT_State_Idle；
中断；

案例 I2C_INT_State_SL_TX：
/*意外操作*/
CurrentConfig[I2C_CHAN_0].TxResult = I2C_EOM_RESULT_UNKNOWN；
CurrentConfig[I2C_CHAN_0].IntState = I2C_INT_State_Idle；
中断；

案例 I2C_INT_State_SL_RX：
/*意外操作*/
CurrentConfig[I2C_CHAN_0].RxResult = I2C_EOM_RESULT_UNKNOWN；
CurrentConfig[I2C_CHAN_0].IntState = I2C_INT_State_Idle；
中断；

默认值：
/*无事可做*/
中断；

｝ /*结束开关(CurrentConfig[I2C_CHAN_0].IntState)*/
中断；

USCI_I2C_UCSTTIFG 案例： /*起始条件(检测到从器件的自有地址)
仅在从器件确定的运行模式时使用
此事务*/
SET_CHANNEL7_HIGH；
IF (0U =(UCB0CTLW0和 UCMST)
｛
/*从模式*/
if (0U！=(UCB0CTLW0和 UCTR))
｛
CurrentConfig[I2C_CHAN_0].IntState = I2C_INT_State_SL_TX；
｝
其他
｛
CurrentConfig[I2C_CHAN_0].IntState = I2C_INT_State_SL_RX；
CurrentConfig[I2C_CHAN_0].RxResult = I2C_EOM_RESULT_IN_PROGRESS；
CurrentConfig[I2C_CHAN_0].IntSlaveRxd = false；
｝
｝
/*开始表示这是一个新事务*/
CurrentConfig[I2C_CHAN_0].ByteCounter = 0U；
SET_CHANNEL7_LOW；
中断；

USCI_I2C_UCSTPIFG 案例： /*检测到停止条件*/
SET_CHANNEL7_HIGH；
开关(CurrentConfig[I2C_CHAN_0].IntState)
｛
案例 I2C_INT_State_SL_TX：//故意掉电*
案例 I2C_INT_State_MA_TX：
CurrentConfig[I2C_CHAN_0].TxResult = I2C_EOM_RESULT_OK；
CurrentConfig[I2C_CHAN_0].IntState = I2C_INT_State_Idle；
中断；

案例 I2C_INT_State_SL_RX：
/*在从机 Rx 模式下、停止条件在物理上发生在接收到最后一个字节后
但中断处理程序中偶尔会有足够的延迟
进入中断处理程序时、Rx 数据和停止条件都存在。
因为停止条件在 UCBxIV 寄存器中具有优先级、用于控制哪一个
中断源已处理、我们需要检查此项并处理最后一个字节
在更改 IntState 之前、否则我们将最终设置接收到的消息
条件、其中一个字节更少、并且忽略后续的 Rx 字节中断*
if (0U！=(UCB0IFG &(UCRXIFG0 + UCRXIFG1 + UCRXIFG2+ UCRXIFG3)))
｛
DataByte = UCB0RXBUF；
if (NULL！= CurrentConfig[I2C_CHAN_0].SuppliedCfg.CfgRxByteCBPtr)
｛
CurrentConfig[I2C_CHAN_0].SuppliedCfgRxByteCBPtr (DataByte、CurrentConfig[I2C_CHAN_0].ByteCounter)；
CurrentConfig[I2C_CHAN_0].ByteCounter++；
｝
｝
/*检查这是一个 Gen 调用还是已寻址消息*/
if (0U！=(UCB0STATW 和 UCGC)
｛
CurrentConfig[I2C_CHAN_0].RxResult = I2C_EOM_RESULT_OK_GENCALL；
｝
其他
｛
CurrentConfig[I2C_CHAN_0].RxResult = I2C_EOM_RESULT_OK；
｝
CurrentConfig[I2C_CHAN_0].IntSlaveRxd = true；
CurrentConfig[I2C_CHAN_0].IntState = I2C_INT_State_Idle；
中断；

案例 I2C_INT_State_MA_RX：
/*检查这是一个 Gen 调用还是已寻址消息*/
if (0U！=(UCB0STATW 和 UCGC)
｛
CurrentConfig[I2C_CHAN_0].RxResult = I2C_EOM_RESULT_OK_GENCALL；
｝
其他
｛
CurrentConfig[I2C_CHAN_0].RxResult = I2C_EOM_RESULT_OK；
｝
CurrentConfig[I2C_CHAN_0].IntState = I2C_INT_State_Idle；
中断；

默认值：
/*无事可做*/
中断；

｝ /*结束开关(CurrentConfig[I2C_CHAN_0].IntState)*/
SET_CHANNEL7_LOW；
中断；

USCI_I2C_UCRXIFG3案例： /*故意掉电、接收到从器件3数据(addr idx = I2C_my_ADDR_quaternary)*/
USCI_I2C_UCRXIFG2案例： /*故意掉电、接收到从器件2数据(addr idx = I2C_my_ADDR_Tertiary)*/
USCI_I2C_UCRXIFG1案例： /*故意掉电、接收到从器件1数据(addr idx = I2C_my_ADDR_Secondary)*/
USCI_I2C_UCRXIFG0案例： /*接收到的数据(addr idx = I2C_my_ADDR_PRIMARY)*/
/*无条件读取数据字节以避免溢出、即使我们放弃它也是如此*/
DataByte = UCB0RXBUF；
SET_CHANNEL7_HIGH；
开关(CurrentConfig[I2C_CHAN_0].IntState)
｛
案例 I2C_INT_State_SL_RX：
/*从机不能控制字节数*/
if (NULL！= CurrentConfig[I2C_CHAN_0].SuppliedCfg.CfgRxByteCBPtr)
｛
CurrentConfig[I2C_CHAN_0].SuppliedCfgRxByteCBPtr (DataByte、CurrentConfig[I2C_CHAN_0].ByteCounter)；
CurrentConfig[I2C_CHAN_0].ByteCounter++；
｝
中断；

案例 I2C_INT_State_MA_RX：
/*主设备控制字节数并生成终止操作。
如果这是倒数第二个字节、我们需要向 STOP 发出信号
未执行自动停止生成*/
if ((I2C_AUTO_STOP_Generate！= CurrentConfig[I2C_CHAN_0].AutoStopType)&&
(CurrentConfig[I2C_CHAN_0].ByteCounter ==(CurrentConfig[I2C_CHAN_0].DataLen - 2U)))
｛
UCB0CTLW0 |= UCTXSTP；/*生成停止*/
｝
/*处理数据*/
if (NULL！= CurrentConfig[I2C_CHAN_0].SuppliedCfg.CfgRxByteCBPtr)
｛
CurrentConfig[I2C_CHAN_0].SuppliedCfgCxByteCBPtr (DataByte、CurrentConfig[I2C_CHAN_0].ByteCounter)；
｝
CurrentConfig[I2C_CHAN_0].ByteCounter++；
中断；

案例 I2C_INT_State_SL_TX：//*故意掉电-意外操作*
案例 I2C_INT_State_MA_TX：//*故意掉电-意外操作*
默认值：
/*无事可做*/
中断；

｝ /*结束开关(CurrentConfig[I2C_CHAN_0].IntState)*/
SET_CHANNEL7_LOW；
中断；

USCI_I2C_UCTXIFG3案例： /*故意掉电、从器件3 Tx 缓冲器空(addr idx = I2C_my_ADDR_quaternary)*/
USCI_I2C_UCTXIFG2案例： /*故意掉电、从器件2 Tx 缓冲器空(addr idx = I2C_my_ADDR_Tertiary)*/
USCI_I2C_UCTXIFG1案例： /*故意掉电、从器件1 Tx 缓冲器空(addr idx = I2C_my_ADDR_Secondary)*/
USCI_I2C_UCTXIFG0案例： /* Tx 缓冲器空(addr idx = I2C_my_ADDR_PRIMARY)*/
开关(CurrentConfig[I2C_CHAN_0].IntState)
｛
案例 I2C_INT_State_SL_TX：
/*从机使用 TxPending 指示响应已可用
一旦所有数据都已用尽、如果主器件请求更多数据
我们只能忽略它并允许主器件对超时做出反应
因为从器件会在等待更多数据时将时钟保持在低电平*/
if ((TRUE =CurrentConfig[I2C_CHAN_0].txPending)&&
(CurrentConfig[I2C_CHAN_0].ByteCounter < CurrentConfig[I2C_CHAN_0].DataLen)
｛
/*如果我们使用 I2C 地址对数据进行前缀处理，则首先进行*/
if (true =CurrentConfig[I2C_CHAN_0].TxPfixMyAddr)
｛
UCB0TXBUF = CurrentConfig[I2C_CHAN_0].SuppliedCfg.CfgMyAddr；
CurrentConfig[I2C_CHAN_0].TxPfixMyAddr = false；//将其清除，因为它只能执行一次并且传输请求特定*/
｝
其他
｛
UCB0TXBUF =*(CurrentConfig[I2C_CHAN_0].TxDataPtr + CurrentConfig[I2C_CHAN_0].ByteCounter)；
CurrentConfig[I2C_CHAN_0].ByteCounter++；
｝
｝
中断；

案例 I2C_INT_State_MA_TX：
/*主器件在进入此状态时将清除 TxPending */
if (CurrentConfig[I2C_CHAN_0].ByteCounter < CurrentConfig[I2C_CHAN_0].DataLen)
｛
/*如果我们使用 I2C 地址对数据进行前缀处理，则首先进行*/
if (true =CurrentConfig[I2C_CHAN_0].TxPfixMyAddr)
｛
UCB0TXBUF = CurrentConfig[I2C_CHAN_0].SuppliedCfg.CfgMyAddr；
CurrentConfig[I2C_CHAN_0].TxPfixMyAddr = false；//将其清除，因为它只能执行一次并且传输请求特定*/
｝
其他
｛

UCB0TXBUF =*(CurrentConfig[I2C_CHAN_0].TxDataPtr + CurrentConfig[I2C_CHAN_0].ByteCounter)；
CurrentConfig[I2C_CHAN_0].ByteCounter++；
｝
｝
其他
｛
/*将数据的最后一个字节传输到移位寄存器、随后的
TXIFG 中断需要在下一个 ACK 后设置停止位的产生
除非我们使用自动停止生成*/
if (I2C_AUTO_STOP_Generate！= CurrentConfig[I2C_CHAN_0].AutoStopType)
｛
UCB0CTLW0 |= UCTXSTP；/*生成停止*/
｝
｝
中断；

案例 I2C_INT_State_SL_RX：//故意掉电-意外操作*/
案例 I2C_INT_State_MA_RX：//故意掉电-意外操作*/
默认值：
/*无事可做*/
中断；

｝ /*结束开关(CurrentConfig[I2C_CHAN_0].IntState)*/
中断；

案例 USCI_I2C_UCBCNTIFG：//*达到字节计数阈值*
由于外设固有的255字节限制、/*当前未使用*/
中断；

案例 USCI_I2C_UCCLTOIFG：//*时钟低电平超时*
CurrentConfig[I2C_CHAN_0].IntState = I2C_INT_State_CLK_ERROR；
中断；

案例 USCI_I2C_UCBIT9IFG：//除地址*之外的每位9个时钟周期(ACK 位置)
/*无事可做*/
中断；

默认值：
/*无事可做*/
中断；
｝ /*结束开关(__even_in_range (UCB0IV、USCI_I2C_UCBIT9IFG))*/

｝/*结束 I2C_USCI_B0_ISR ()*

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

    您好 Steven、

    代码部分较长、但有一些一般性问题：

    1.你是否使用 LPM (如果是)哪些是？

    2.您的 CPU 和 eUSCI 使用哪些时钟？

    其他哪些模块可以驱动中断？ 您是否尝试禁用所有其他中断源？

    4.如果设备(始终正确接收？) 停止总线如何再次释放(通过 WDT 或 RST 引脚)？
       您能更好地描述一下、如果接收器卡滞、会发生什么情况吗？ 是否有任何其他函数起作用、或"仅"I2C 发生故障？

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

    Dietmar、

    很抱歉、代码较长、但中断对于所有多主控 I2C 操作都是通用的、因此可处理主控 Tx、主控 Rx、从控 Tx 和从控 Rx。

    1、否、不使用低功耗模式。

    主时钟是在8MHz 时生成的 DCO： 

    void SYS_init( void ){

//振荡器设置
CSCTL0_H = 0xA5； //解锁寄存器
CSCTL1 = DCORSEL + DCOFSEL0 + DCOFSEL1；// DCO 设置
CSCTL2 = SELA_1 + SELS_3 + SELM_3； // ACLK = VLO、SMCLK = MCLK = DCO
CSCTL3 = DIVA_0 + DIVS_0 + DIVM_0； // CLK 分频器
CSCTL0_H = 0x01； //锁定寄存器

    UART 时钟为 SMCLK： 

    /*为 I2C 操作配置 eUSCIBx */
/*将 eUSCI 默认为 I2C 模式、7位寻址、多主器件、
(主器件)时钟源 SMCLK (8MHz)*/
UCB0CTLW0 =(UCMODE_3 + UCSYNC + UCMM + UCSSEL_SMCLK + UCSWRST)；

/*默认时钟低电平超时34ms、无自动停止生成、
去毛刺脉冲时间50ns (指定了 I2C)*/
UCB0CTLW1 =(UCCLTO0 + UCCLTO1)；

    使用多个中断：
    USCI_A0_Vector
    USCI_A1_Vector
    USCI_B0_Vector
    TIMER0_A0_VECTOR
    TIMER3_A0_VECTOR
    TIMER2_A0_VECTOR
    ADC12_矢量

    我尝试删除 ADC 中断、观察到的问题没有变化。
    模块运行所需的所有其他组件、因此无法轻松禁用。
    进一步调查需要编写一个特定的测试项目、以便能够消除这些中断源。

    4.我已经确定始终是将时钟保持在低电平的从接收器。
    时钟低电平超时中断被配置和启用、检测(主器件和从器  件都是常见的代码)导致非中断状态控制复位状态、通过 UCB0CTLW0 = UCSWRST 复位 UART、然后重新初始化 UART 以用于 I2C 并继续。
    此复位过程正常、当前消息丢失、但一旦复位、应用程序将继续传递数据包、直到下一个时钟保持低电平事件发生大约100、000条消息。 (应用程序的主器件轮询从器件接收器的时间大约为每40ms 一次。)

    仅 I2C 通信似乎受到影响、其他功能继续运行(I2C 代码专门设计为非阻塞)

    谢谢
    Steven。

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

    此外：

    这是100kHz 时的 I2C。

    也是在400kHz 下尝试的、结果相同。
    但是、由于从 UCRXIFGn 中断中调用的 Rx 数据处理回调函数速度不快、它可能需要与400kHz 时的 Rx 字节花费大约相同的时间、这可能会导致其他问题、因为某些时钟拉伸是不可避免的、因此会恢复到原始100kHz 速率。
    但是、这种对400kHz 下某些所需时钟拉伸的引入对卡在低电平特性的观察速率没有任何影响。

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

    您好 Steven、

    感谢您提供的信息、因此最好知道"只有"I2C 模块受到影响、并且器件仍然能够检测到对其的超时响应并复位 eUSCI 模块以使其再次正常工作。

    那么、另一个问题是、您可以通过在 SCL 上触发示波器来记录最后一个工作周期的 SCL 和 SDA、以实现超时。 可能会对时钟或数据产生干扰感兴趣。 您认为可以检查一下吗？ 您使用了哪些上拉值？

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

    Dietmar、

    遗憾的是、我目前无法在连接示波器的情况下重新创建条件、我已进入项目中的另一条关键路径、目前无法花费不确定的时间进一步调查这一点。
    但是、我确实根据 I2C 要求在50ns 启用了外设 I2C 干扰滤波器。

    SDA 和 SCL 上的上拉5k 欧姆至+3V3

    在搜索此论坛时、我注意到以下内容有一些相似之处、但遗憾的是、我注意到根本原因从未被发现、只是通过自定义超时来解决。 当前、我等待 I2C 外设时钟低电平超时、然后复位外设。
    他们的猜测围绕多个具有竞态条件的中断、这符合观察到的问题的时间/速率。

    https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/804617

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

    Steven、

    嗯... 在没有信号细节的情况下、很难说、但我使用4.7kOhm 上拉电阻器但走线很长的情况下的 I2C 有问题。

    I2C 不时因为从器件未应答而卡住。 原因是信号太差、无法正确识别地址。 我将其减小到了1.5kOhm、并且工作正常。 重点是有10个从器件和一个主器件、我们有很长的布线。

    也许您可以对其进行试验并减少上拉电阻、使其更强、从而使线路的更大电容变得不太重要。
    长时间再运行一次、看看卡滞情况是否仍然发生。

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

    您好 Steven、

    您是否有机会尝试其他上拉？ 我将把这篇帖子保持开放状态、直到一周结束(11月15日)、等待更新、然后关闭它。

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

    Dietmar、

    我目前无法访问硬件、我将尝试再次设置故障条件、但可能需要几天时间。

    虽然我不会消除上拉值、噪声或糟糕的信号形状、但作为软件工程师、这对我来说是不合理的。
    您观察到的问题是由于从器件不对数据进行堆栈、但在我的情况下、从器件必须成功对前一个字节进行了确认、否则主器件将不会继续传输。 在发现问题的情况下、接收器没有对最后一个字节进行应答、因为接收器在最后一个数据位之前将时钟保持在低电平、因此它永远不会到达 ACK 时隙。
    从逻辑上讲、这是与您观察到的情况不同的症状。

    同样 、如果从器件由于噪声问题未接收到数据位或时钟位、那么保持时钟低电平的接收器将是一件奇怪的事情、尤其是在一个字节内的同一第7位位置。

    如果接收器在数据或时钟上看到噪声、那么考虑到启用的毛刺脉冲滤波器、它肯定会对数据执行操作、并且在接收到杂散时钟时接受该操作、或者可能看到杂散启动/停止条件并执行相应操作。 我不认为接收器执行的任何操作都是顺序错误的、但可能是错误的。

    我将尝试重新构建硬件和软件、以生成故障并报告。

    谢谢、
    Steven。

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

    Steven、

    感谢您的回答。 我同意，我所说的并非是根本原因，而是应该根据我的经验提出一些想法。

    如果您能够更好地限制接收器卡住时的条件、将有助于进一步讨论可能发生的情况。 因此、我们期待您的网站提供更多数据。

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

    请不要关闭、我目前正在重建开发硬件以重现故障。

    然后、我将使用 "波形布线和上拉值"提供更多信息。

    谢谢。

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

    Steven、

    感谢您的更新、我们将保持开放、期待您提供更多信息。 如果在测量过程中有任何问题、请随时联系我们。

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

    Dietmar、

    我最终成功执行了一些其他测试、看起来您是正确的、因为上拉值是根本原因。

    我已经设置了原始配置、并且可以在大约1小时的间隔内重复触发相同的观察到的时钟保持低电平行为、大约每100、000条消息发生一次。
    我最初的上拉假设中的假设不正确、事实证明原始硬件使用的是10k 欧姆上拉电阻。

    添加了2k2并联、总计约1k8、并在无其他更改的情况下重复测试。
    现在测试已运行30个多小时、没有问题。

    我很高兴接受上拉电阻值是导致观察到的行为的原因。
    感谢你的帮助。

    Steven。

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

    Steven、

    很高兴听到这样解决了这个问题。 非常感谢大家的积极反馈、我们对此深表感谢。