[参考译文] MSP430FR59941：eUSCI 软件复位

Luke、

"没有设定数量的时钟周期或它需要被保持的时间。"

基于什么？  说是谁/什么？

此致、

A

让我详细说明一下。。。

我知道有一些设置只能在 eUSCI 未运行时进行。  但我没有看到任何地方说复位条件必须保持 X 个时间。  但是…

当我使用复位和连续取消复位时、我会看到时钟线在脉冲下自由运行、并且没有数据线操作。  很明显、eUSCI 不处于稳定状态。

此致、

A

您好、A：

您要重置 eUSCI 的上下文是什么？ 您只是尝试更改某些设置还是将模式更改为不同的通信接口？

我们不会列出所有寄存器复位所需时间的任何信息。

此致、

Luke

操作是立即停止任何和所有 I2C 流量。  重置主设备将/应该停止时钟、从而停止所有流量。  

我看到的是... 当我将主器件从复位中拉出时、... 我的目标是获取点击~350mSec 的时钟、或者获取传输的剩余 I2C 器件地址。  这两种情况都不应发生。  复位：IFG 被清除、。。 IE 被清除

所以... 我想知道 eUSCI 为什么这么做？

此致、

A

您好、A：

我查看了我们的示例代码并进行了一些修改以重置 UCB2、但没有看到任何遗留信号。 您可以在复位 USCI 时为上下文发送代码片段吗？  

此致、

Luke

Luke、

I2C 通信失败时出现问题。  我建议您使用的内容不会遇到此问题、因此您不会看到剩余的操作。  当流量为 propper 时、不存在重置故障/问题。  始终会发生复位。  基本上是为了纠正总线挂起的问题。  挂起的总线会消失、但被不需要的 Tx 活动所取代、这会拖掉下一个传输(接收器现在正在看到垃圾通信活动)。

我尝试附加几个跟踪图像、但我从未让您的网站合作。  因此、我无法向您展示我看到的内容。

问题详细信息：通常故障是总线挂起。  它通常看起来第一个位丢失(从未发送)、然后字节永远不会获得 ACK / NACK (因为位计数关闭)。  我不确定是什么导致位丢失。  也可以发送第一个位、但这意味着之前的字节 ACK 位永远不会被发送/看到。  如果为 true、则问题字节应该从未发送。

我用来重置 eUSCI 的内容：   (bash 它翻转了头部一次)

 *ucbxctlw0 |= UCSWRST__ENABLE；  //软件复位中的 USCI
//does not help clock->DelayMilliseconds (10)；
 rxBuff->clear()；   //清除缓冲区
 txBuff->clear()；
 *ucbxctlw0 &=~UCSWRST__ENABLE； //退出软件复位

我现在使用的是：   (两次将它翻转头部)

 *ucbxctlw0 |= UCSWRST__ENABLE；  //软件复位中的 USCI
//does not help clock->DelayMilliseconds (10)；
 rxBuff->clear()；   //清除缓冲区
 txBuff->clear()；
 *ucbxctlw0 &=~UCSWRST__ENABLE； //退出软件复位
 *ucbxctlw0 |= UCSWRST__ENABLE；  //软件复位中的 USCI
 *ucbxctlw0 &=~UCSWRST__ENABLE； //退出软件复位

第一种方法显示出大量剩余的通信操作。

第二种方法显示的较少、但仍然存在随机的剩余通信操作。

此致、

A

void I2cSlaveB0::ISR(){
_disable_interrupt ()；//禁用全局中断 GIE= 0
 switch (__evo_in_range (UCB0IV、UCIV_UCBIT9IFG))   
 ｛//最高优先级
   案例 UCIV__UCNACKIFG：          //向量0x04
       UCB0IV=0； //清除所有待处理的 INT
       numRxBytesLeft = 0；
       numTxBytesLeft = 0；
       rxBuff->clear()；   //清除缓冲区
       txBuff->clear()；
     中断；

   案例 UCIV_UCSTTIFG：           //向量0x06
     UCB0IE &=~UCSTTIE_1；   
     IF (UCB0CTLW0和 UCTR)  
       UCB0IE |= UCTXIE0_1；  
     否则 ｛                 
       numRxBytesLeft = 0；   
       numTxBytesLeft = 0；   
       UCB0IE |= UCRXIE0_1；  
     ｝
     中断；  

   案例 UCIV_UCSTPIFG：           //向量0x08
     IF (UCB0CTLW0和 UCTR)｛
       txBuff->clear()；
       UCB0IFG &=~ UCTXIFG0；  
     ｝
     UCB0IE &=~UCSTPIE_1；  
     UCB0IE |= UCSTTIE_1；   
     中断；

   案例 UCIV__UCRXIFG0：         //向量0x16
     unsigned char rxData = UCB0RXBUF；       
     rxBuff->Insert (rxData)；          
     //对 Rx 数据执行一些操作，对 TX 数据进行格式化

     //接收到该 TX 的最后一个字节       
       UCB0IE &=~UCRXIE0_1；  
       UCB0IE |= UCSTTIE_1；  
     ｝
     中断；

   案例 UCIV__UCTXIFG0：         //向量0x18
     if (！txBuff->IsEmpty())｛
       unsigned char TX = txBuff->Remove()；          
       UCB0TXBUF = TX；         
       如果(！(-numTxBytesLeft)｛   //尚未完成？
         UCB0IE &=~UCTXIE0_1；  
         UCB0IE |= UCSTTIE_1；  
       ｝
     ｝
     中断；

   案例 UCIV__UCCLTOIFG：        //向量0x1c
     i2cClkLoTimeOutErrFlag= true；
     中断；
                     
   默认值：
     中断；
 ｝
_enable_interrupt ()；
｝

复位代码位于主器件上。

ISR 代码是从器件。

您好、A：

对于我来说、在附加图像时、我必须插入、每次只能输入一个图像、大多数时候我也可以复制和粘贴屏幕截图。

当您执行  *ucbxctlw0 |= UCSWRST__enable 时，是否可以放置断点？ 在这里检查寄存器视图上的寄存器、它们应该复位为0。 单步执行清除、并验证缓冲区是否已被清除。 当 eUSCI 处于复位状态并且您清除缓冲区时、我不会期望发送任何剩余字节。 验证缓冲区和寄存器是否已清除后、运行程序并查看是否再次发送"垃圾"数据。

如果确实发送了回收站数据、我会看到它是否实际来自目标器件。

如果您在重置 I2C 控制器器件时正在从目标器件接收数据、我会感兴趣。 它最终应该自行解决、但这将是您看到垃圾数据的原因。

此致、

Luke

我在 SWRST 周围清除/设置 PSEL 位(SCL 优先/最后)方面取得了一些成功。 巴士可能会因多种原因而停机、因此这是一项混乱的业务。

未经请求：

(1)我对在从器件中使用 STPIFG 非常谨慎、因为它可能会先于最先出现的其他状态(尤其是 RXIFG)出现。 此外、如果是重复启动、则没有停止。

(2)我建议您不要在 ISR 中启用中断。 当 ISR 返回时、硬件会将 GIE 放回。

这是对问题的模糊看法。  左侧显示总线被挂起。  右侧显示了问题所在的"额外"剩余活动。

这是对左侧的详细介绍。  它显示总线由于缺少 ACK/NAK 而被挂起。  0x45实际上是对器件0x22的读取、... 错误签署 ACK。  我已经在这方面进行了一段时间。  我发现 Bruce 的评论很有趣。  (稍后更多)

这是对右侧的详细介绍。  它显示了剩余的"额外"流量。  当绿线变为高电平时、SWRST 发生、... 基本上、当"额外"活动开始时。

我在 SWRST 打开和关闭的中间添加了缓冲区刷新调用、... 希望硬件在此期间完成复位。  由于 SWRST 清除了 InterruptEnable 和 IFG 寄存器、缓冲区刷新不应影响 I2C 通信。  即、不启用 IE、... 不应存在来自 eUSCI 的中断请求。  但图像显示管道中仍有一些东西。  时钟只能来自主器件。。。 问题就在这里。

我很难使用调试器、因为它会减慢进程速度。  即、我使用和不使用调试器时会出现不同的行为。  请记住、当我停止处理器时、它不会停止 eUSCI。  让我尝试一下您的"在 SWRST 上暂停建议"。

此(中间)跟踪显示正常的完成写入事务、后跟有人拉伸时钟的读取。 由于这是一个读取操作、它可能是从器件忽略其 TXIFG [参考 UG (SLAU367P)图32-9、左上角的"总线停止"]。

是的、我理解这一点。  这是我在从 ISR 方面遇到的一个重大问题。  也就是说、。。 (有时)在从站 Tx 过程中、它将在同一 ISR 周期内完成并获取以下 Rx 请求。  即 IFG = 0x0F (STT、STP、Rx、TX)、而不是预期的0x0A (STP、Tx)。  STT 的优先级高于 STP、... 就像 Rx 具有比 Tx 更高的优先级一样、... 因此、Rx 获得服务、而 Tx 不获得服务。  即 Tx 缓冲区永远不会获取数据... 因此它会停止。  (这是另一个问题。)

注释：

我在 ISR 中处理了 STP、但发现它很麻烦、所以我将其删除。  这有助于解决某个问题、但现在我遇到了 IFG=0x0F 的问题。  即、我无法单步执行以下状态：STT Rx STP、... STT、TX、STP、...

我在 ISR 中确实有 NACK、但它从未受到影响。  我发现这很奇怪。  作为 Tx 周期结束的 NACK 不会触发它。  我不明白为什么不这样。

Bruce、

"我建议您不要在 ISR 中启用中断。 当 ISR 返回时、硬件会将 GIE 放回。"

我看不到这是用户指南。  

我看到一些代码使用了_bis_SR_register (GIE)、但我从未找到有关如何使用它的指导。  我看到一个 ISR 具有_bis_SR_register (GIE)、但没有提到_BIC 或 disable_interrupts、... 那么、您为什么需要__ bis？   这种"如何使用"___ bis/__ BIC 是否记录在任何位置？

"当 ISR 返回时、硬件会将 GIE 放回何处"的信息在哪里？

谢谢

TXIFG 和 RXIFG 置1似乎有点奇怪、因为对于给定的传输、您只能看到 TXIFG (从发送器)或 RXIFG (从接收器)。 (我怀疑其中一个交易是从之前的交易中遗留下来的。) 这种情况的一个后果是、由于 IFG 会告诉您要做什么、因此始终将 RXIE 和 TXIE 保持置1可能是合理的。

我注意到、对于一个 TXIFG、如果你没有任何东西需要发送、你根本不发送任何东西(写入 TXBUF)。 我不认为[根据图32-9和第32.3.7.2节]这是您的选项之一。 如果数据用完、请发送填充字节、但需要发送一些内容来管理流控制。 (主机意外读取或写入一个过多字节的情况并不少见。) 您始终在 RXIFG 上读取 RXBUF、但前提是 RXIE 在适当的时间被置位。

[编辑：更正了拼写错误。]

UG 章节1.3.4描述了中断序列、包括保存/恢复 SR (包含 GIE)。

ENABLE_INTERRUPT 和 DISABLE_INTERRUPT 是围绕__BI[s|c]_SR_register (GIE)进行包装的、但其中一个中有一个 NOP 可处理第1.3.4节("注释")。

我看到很多这些未知的摊位。  它们是随机发生的。  我不能将它们归于 ISR 执行、但它们会在 ISR 执行期间发生。  我猜它们来自 NMI 操作。  可能是看门狗服务。  还有人看到这些吗？  (我想知道这是否是我的一个隐性问题。)

解析此跟踪有点困难、但看起来一方或另一方(偶尔)没有及时处理其中断。 时钟拉伸本身并不坏、但通常情况下、时钟拉伸的效果要比其他时好得多。 您的代码还在做什么？ 您是否在任何地方禁用中断？

除非您的代码使用 NMI 或看门狗执行某些操作、否则我希望其中任何一个操作会挂起/复位您的系统、而不会恢复、因此这些原因似乎不太可能出现。

Luke、

我已经验证了 SWRST 操作。  eUSCI 寄存器确实清除了。  当之前的 I2C 通信挂起总线时、我仍然会获得"额外"通信。  即、这种"额外"流量似乎仅在总线被挂起时发生。  (但这正是 SWRST 操作的全部原因、。。 以恢复挂起的总线。)  这是我之前提到的"无限" CLK 的轨迹。  SWRST 之后(在下降白色轨迹处)、它会在~340mSec 内停止。

Bruce、

我相信您是正确的。  STALL 始终出现在 ACK 中。  我仅在从器件处于 Tx 事务时才会看到它。  即主器件 ACK 速度慢。  我只是想了解它的来源。  (我认为这不是问题。)

查看 UG 1.3.4.1和1.3.4.2后、我移除了 ISR 内的启用和禁用中断调用。  我看不到 ISR 操作中没有原因说明的差异。  这使我对我在其他发布代码示例中看到的_ bis_SR_register (GIE)调用提出质疑。  我终于看到了 GIE=0的来源。  谢谢你

您能详细说明吗？  我猜您正在取消选择 eUSCI、然后执行 SWRST 操作、然后重新选择 eUSCI。  在 SWRST 期间、基本上将外设与引脚隔离。  这似乎是解决单个"额外"字节问题的解决方案。  但我怀疑这将对"无限"的 CLK 问题有所帮助。

我对此感到困惑。  我已经看到代码会将额外的字节填充到 Tx 中。  对我来说、这似乎是一个错误、因为听众如何知道他们(额外字节)是否是真实响应的一部分。  或者、侦听器如何知道现在需要将负载增加一个？  似乎更好的分配办法是取消交易并重新开始交易。  那么、为什么要尝试添加额外的字节呢？  (只是浪费时间。)

我不时看到这种“永恒的停止”(也是“永恒的开始”)症状，我总是在巴士上做一些不寻常的事情。 我怀疑它与总线监控器有关、在某种程度上看不到 SDA 转换(尽管我们可以在那里看到它)。

我在测试总线挂起复位代码时看到了它、我还记得(这是一段时间前)、当我更改 PSEL 版本以让 SCL 首先运行、然后是 SDA 时、它被清除。 当时我怀疑这与制造看起来模糊的东西有关、比如"停止"条件。 (我不知道 EUSCI 的内部工作原理。)

两侧是否在总线超时自行复位？

> 侦听器如何知道它们(额外字节)是否是真实响应的一部分

从设备如何知道主设备需要多少数据？

从机对总线没有太多的控制--它不控制时钟(信号)或 SLA 或(对于从机发送器) ACK 周期，也不能停止事务。 它所具有的唯一控制是保持 SCL 为低电平(拉伸时钟)、但这并不是很有用、因为它已经被用来表示"只等待一会"。

因此、如果主器件在从器件认为它已经耗尽后请求从器件提供数据、那么唯一的选择是(a)提供一些(虚拟)数据或(b)挂起总线。  

主器件获取 SWRST 和 UNSWRST。  该器件通过 HW 从总线断开。

主设备和从设备都知道传入和传出的字节数。  (协议是固定的。)      我想知道如何从响应中间的已添加字节中恢复、而不仅仅是在结束时  (如您所建议。)

我的印象是、我没有在代码中做任何不当的事情。  这就是硬件的工作方式。  我需要找到一种解决这些特性的方法。

感谢您的深入了解