[参考译文] CC3200：I2C 通信问题

你(们)好

是的、我尝试了断点

当我逐步运行时、所有工作正常

此致

哈里齐-  

我可以在 SDK 中看到 i2c.c 文件、这里=>C ：\ti\cc3200SDK_1.1.0\cc3200-sdk\driverlib 您可以使用定位文件按钮检查该文件吗？

自该版本发布以来、我们还更新了 SDK 两次-如果您想更新或再次获取 v1.1、请访问此处=>  

你(们)好

我们尝试禁用传感器任务并使用 LED 任务运行程序、但每次我们都遇到与第一个帖子中相同的问题。

如 下面的屏幕截图所示、该程序卡在 I2C 函数中。

剩下的 LED 任务是唯一使用 I2C 通信的任务、因此我不认为是这样。

此致。

你(们)好

抱歉进行双帖子

但我们只使用逻辑分析仪来查看 I2C 数据。

在 I2C 写入函数中的程序块之前、一切都正常。

在此屏幕截图中、我们可以看到使用 write 命令发送的部分最后数据 trame、注册表写入、但没有值、时钟保持低电平状态。

在另一个屏幕截图中、您可以看到在"最后一个数据帧"之后4.488ms 出现了一些奇怪的情况。

在这里、如果通信能够帮助、则是对通信结束的全球愿景。

非常感谢您的帮助

此致

你(们)好 

您可以在此处找到 LED 任务的初始化函数： 

void ledTask_init()
{
unsigned char config[3]=｛0x00、0x21、0x04｝；
unsigned char cmd_init_off[5]=｛0x06、0x00、0x00、0x10｝；

I2C_IF_Open (I2C_MASTER_MODE_FST)；
I2C_IF_Write (Board_PCA9685_ADDR、CONFIG、3、TRUE)；
I2C_IF_Write (Board_PCA9685_ADDR、CMD_INIT_OFF、5、true)；
I2C_IF_CLOSE ()；

OSI_SyncObjCreate (&g_ledStatSyncObj)；

OSI_TaskCreate (LED_manager、
(const signed char *)"LED Manager"、
OSI_STACK_SIZE、
null、
1、
null)；

GG_ulBase = TIMERA3_base；//设置计时器地址
Timer_IF_Init (PRCM_TIMERERA3、g_ulBase、TIMER_CFG_PERIODICRACRAE、TIMER_A、0)； //配置计时器
TIMER_IF_IntSetup (g_ulBase、TIMER_A、TimerledHandler)；//针对计时器超时设置中断
Timer_if_Start (g_ulBase、timer_A、5000)；//以毫秒为单位启动计时
器｝ 



以下是任务函数： 

void led_manager (void *pvParameters)
｛
volatile unsigned char LoopVar = 0xFF；

while (LoopVar)
｛
OSI_SyncObjWait (&g_ledStatSyncObj、OSI_WAIT_FOREVER)；//OSI_WAIT_FOREVER

I2C_IF_Open (I2C_MASTER_MODE_FST)； 

呼吸()；
change_color_led ('W')； 

I2C_IF_CLOSE ()；
｝
｝ 

最后、您可以在这里看到将控制 LED 的呼吸功能

作为全局变量：

unsigned char rregister[4]=｛0x0A、0x16、0x2E、0x22｝；
unsigned char cmd_for_all[13]=｛0x00、0x00、0x00、0x00、0x00、0x00、0x00、0x00、0x00、0x00、0x00、0x00｝；//按颜色更改 func 修改 

void 呼吸()
{
静态 char 状态= 0；
静态 int 值= 0；
字符 inc = 100；
静态字符速度= 0；
字符 I；

如果(状态= 0)
｛
如果(值< 4096)
｛
变压器环颜色(值)；
对于(I = 0；I < 4；I++)
｛
CMD_for_All[0]= rregister[i]；
I2C_IF_Write (Board_PCA9685_ADDR、CMD_for_all、13、true)；
｝
值+=(值< 2000？ (值< 1000？ (int) inc / 2：(int) inc)：(int) inc * 2)；
｝
其他
｛
值= 4095；
状态= 1；
｝
｝
其他
｛
如果(值> 0)
｛
变压器环颜色(值)；
对于(I = 0；I < 4；I++)
｛
CMD_for_All[0]= rregister[i]；
I2C_IF_Write (Board_PCA9685_ADDR、CMD_for_all、13、true)；
｝
值-=(值< 2000？ (值< 1000？ (int) inc / 2：(int) inc)：(int) inc * 2)；
｝
否则(值< 0 &&速度= 0)
｛
变压器环颜色(值)；
值= 0；
对于(I = 0；I < 4；I++)
｛
CMD_for_All[0]= rregister[i]；
I2C_IF_Write (Board_PCA9685_ADDR、CMD_for_all、13、true)；
｝
Tempo ++；
｝
否则(值= 0 &速度< 16)
｛
Tempo ++；
｝
其他
｛
值= 0；
状态= 0；
速度= 0；
｝
}

void transformCircleColor (int value)
｛
if (cmd_for_all[2]！= 0)
｛
CMD_for_All[2]= 0x00；
CMD_for_All[3]=值；
CMD_for_All[4]=值>> 8；
｝
if (cmd_for_all[6]！= 0)
｛
CMD_for_All[6]= 0x00；
CMD_for_All[7]=值；
CMD_for_All[8]=值>> 8；
｝
if (cmd_for_all[10]！= 0)
｛
CMD_for_All[10]= 0x00；
CMD_for_All[11]=值；
CMD_for_All[12]=值>> 8；
｝
if (cmd_for_all[7]！= 0 || cmd_for_all[8]！= 0)
｛
CMD_for_All[7]=值/2；
cmd_for_all[8]=(值/2)>8；
｝
｝ 

感谢你的帮助

您好！

代码对我来说也很好。 在您提供的第一个波形中的 ACK 之后、故障是否持续发生？ 我们的目标是在每次未能进一步调查时查看是否有模式。

此外、我注意到 SCLK 在下面标记的2个之前的事务之间保持低电平。 如果在每笔交易之间发生这种情况、可能值得调查。

此时、我认为最好的做法是分析捕获的波形、以确保一切都按预期进行。

Jesu

你(们)好

在 TI 论坛上进行了大量有关 cc3200和 I2C 的研究之后，我们发现这篇文章： e2e.ti.com/.../603942

 在这篇文章中，Jan D福音 是一个在 I2C 通信被卡住时重新进行通信的提示：

-将 SCL 处的 punumx 设置为 GPIO 和输出
-在 SCL 上生成一些脉冲(直接设置高电平和低电平、在这种情况下不使用上拉电阻器来驱动高电平状态)
-将 punmux 设置回 I2C SCL
-重新初始化 I2C 外设

为此、我们尝试应用该文档第16.2部分中的修复  

这不起作用，但我们不确定 在哪里必须调用 I2cEmimulation()函数。

感谢所有帮助

此致

您好！

您的 I2CEmulation 调用看起来是正确的、但我认为您不会到达那里、因为您报告说您在上面的 while 循环中遇到困难。 您能否确认 SCL 在两次交易之间是否保持低电平？ 此外、同一从器件是否始终发生 I2C 故障？

Jesu

你(们)好
我向您确认、SCL 在两次交易之间保持低电平。
I2C 故障每次都在同一从器件上发生。

我用逻辑分析仪做了一条新记录、这是程序卡滞之前的最后一条通信。

使用 ACK 写入命令正常、但之后...

这不可能是因为时钟不是完全正常的？

此致

你(们)好、Jan

我们只需使用示波器查看 边缘，就可以看到：  

信号看起来正常、因此这显然不是硬件问题。

感谢您的帮助

此致

您好！

SCL 线路看起来正常、但在 SDA、您在高电平状态下会出现奇怪的0.3-0.4V 毛刺脉冲。 它们不应该在那里。 您的 I2C 总线的电容也不会看起来很低。
-您的 I2C 总线有多长时间？ 您连接了多少个从器件？ 您使用什么 I2C 从设备？ 什么是有问题的从属设备？
－您使用的上拉电阻值是多少？ 您是否尝试使用更强的上拉电阻？
-您的所有 I2C 从器件是否都设计为在400kHz I2C 下使用？
-您是否尝试将时钟降低至100kHz？
-您是否能够在示波器时刻捕获从设备卡住的情况？ 是的、我知道这可能很棘手、您需要使用外部触发器。

1月

你(们)好、Hnz

-您的 I2C 总线有多长时间？
SDA：75、5mm (宽：0、15mm)
SCL：77毫米

您连接了多少个从器件？
2.

您使用什么 I2C 从设备？
PCA9685PW (LED 驱动器)
SI7020-A20-GM1 (温度传感器)

什么是有问题的从属设备？
使用 LED 驱动器实现 I2C 冻结(PCA9655)

－您使用的上拉电阻值是多少？ 您是否尝试使用更强的上拉电阻？
我使用的是5k 上拉电阻器，我也尝试了1k 电阻器，但仍然有问题。

-您的所有 I2C 从器件是否都设计为在400kHz I2C 下使用？
是的

-您是否尝试将时钟降低至100kHz？
是的、相同问题

-您是否能够在示波器时刻捕获从设备卡住的情况？ 是的、我知道这可能很棘手、您需要使用外部触发器。
我使用逻辑分析仪进行了记录(屏幕截图位于线程上方)、但使用示波器、我不确定是否成功、我将尝试。

此致

您好！

与 PCA9685的通信卡滞的频率如何？ 您能否估计数字(例如、1000个请求中的一个等)。

由于某些原因导致 PCA9685芯片中的内部逻辑出现问题、我几乎100%确定。 现在、我们来问一下它的频率是多少。 如果经常出现问题、您需要在硬件方面解决此问题。 但是、如果发生这种情况、就很少有理由更改软件方面的内容。 添加额外超时和测试可能是合理的。 如果 SCL 卡在低电平、可能是重要的错误 I2C_MASTER_ERR_ARB_Lost。

我的个人意见。 我从未在 CC3200 SDK 中使用_IF 抽象层。 这一层中的函数不是很可靠、使用它们会浪费 CPU 时间。 使用中断甚至 DMA 更高效。

更新：

只需确保。 如果卡住、它会一直保持在 I2CTransact()中的 while 循环中、并且没有返回？ 对吧？

1月

大家好、

感谢 Jan 我还想补充一下、软件侧修复是否合理-您可能可以在预期故障发生之前定期在 LED 驱动器上触发软件复位。 PCA9685具有通过 I2C 总线实现的软件复位功能。 希望了解定期软件复位是否可以防止 i2c 故障。

Jesu

大家好、

对 Jesu：是的、我尝试使用 PCA9685模块的复位功能、但它没有执行任何操作、始终会发生相同的故障。

到 Hnz：对，当它被卡住时，它永远留在 while 循环的 I2CTransact()中，永远不会返回。

与 PCA9685模块的通信每次都绝对卡住，速度非常快(< 1次二次)。

一直都很感谢

路易森

您好 Louison、

如果经常出现通信中断、我认为无法通过软件解决此问题。 您需要修复您的硬件。 但您的案例中有什么错误是一个好问题。 您是否测试了更多 PCA9685芯片？ 您是否使用另一个 MCU 测试了 PCA9685芯片？ 我们可能忘记了明显的潜在问题原因之一-芯片损坏或一些 EMC 问题。

软件解决方案不是您的问题、但如果问题的发生率较低(假设所有通信的1%)、则可以合理地增加故障状态检测、例如：

unsigned int err；

while (((err = MAP_I2CMasterIntStatusEx (I2C_base、false))&(I2C_INT_MASTER | I2C_MRI_CLKTOUT | 0x80))= 0)
{
}

//仲裁丢失原始中断状态(0x80是 I2CMRIS 寄存器中的 ARBLOSTRIS 标志)
(如果

是过程(err 和 I2CMSCL= 0x80)，则为0x80)/chulses！/(通过生成 I2C！/chum脉 冲)
//在执行此过程后还应重新启动 I2C 外设。
//
｝ 

但我认为此代码不能为您节省成本、因为您与 PCA9685芯片的通信非常不可靠。

1月

大家好、

我有新消息！ 我们现在可以确认这不是硬件问题！

请记住、projet 基于 Blefi 示例项目。

当 LoadBleFiCfg()函数 在 GwGenericTask 中具有一致性时，LED 运行良好。 如果调用此函数、则会发生问题。

但是、如果该函数具有组内音功能、那么蓝牙和 MQTT 等功能将无法正常工作。 当然是因为他们没有配置。

我不知道该函数如何影响 I2C 通信、但会发生这种情况。

再次感谢你们的帮助！

此致

您好！

@Hnz 您是对的、CCA 不确定它不是硬件问题、但 I2C 总线和 BLE 天线之间的距离很小、只有2cm。 我没有 频谱分析仪来测试它。

@Jesu 蓝牙在 CC2650器件上运行

此致