[参考译文] BQ78350-R1：安全状态读取错误处理

Daniel、您好！

很抱歉耽误你的回答。 本周、我们所在地区发生了断电和互联网中断。

BQ78350在为连接到 BQ769x0电池监控器的 I2C 总线提供服务时占用了一定的带宽、因此有时、如果处理器繁忙、SMBus 命令会发出否定应答。 对于 ManufacturerData 命令、我不确定是否会有任何差异、但您观察到读数更快、显示出更多问题、这让我怀疑这一点。  

是否有原因不使用0x51直接命令？

此致、

Matt

尊敬的 Matt：

非常感谢您的快速响应！

在我看来，更深的问题一定是错误的。
错误完全随机发生。
我添加了一些睡眠模式、以查看是否有任何差异、
但仍然是1、2、3或4字节变为0xFF、甚至是随机的0x0F。

因此、我尝试了您建议的更改 SMBus 命令的内容。
但0x51命令根本不起作用。 我对总线的写入会卡住。
我使用0x09 0x14或 0x4F 等不同的命令测试了这一点。
所有命令都运行良好。
但是、一旦我尝试使用0x51、总线似乎不再响应。

我不知道有什么具体差异吗？
这甚至是文档中表17.1中建议的 SMBus 命令吗？
我是否必须以不同的方式发送命令？
使用 uint8_t 可能不正确？

www.ti.com/.../sluubd3e.pdf

很奇怪、它被记录为 SMBus 命令、但没有
如何使用它的说明。

或者、您是否参考了 ManufacturerBlockAccess 而不是 SMBus 命令？

此致

Daniel

您好、再说一次、

我刚刚找到、该文档显示了17.1中的 SMBus 命令、然后解释了制造商访问、然后再次解释了 SMBus 命令。 如果这是正确的、则会引起非常混乱的情况。

无论如何、我发现 SafetyStatus SMBus 命令是17.46中所述的块命令。
对于电压、我将0x09写入总线、然后从总线读取响应。
我担心 SafetyStatus 的工作方式会有所不同。 我必须直接从寄存器中读取、对吧？

I2C 块读取：i2C_smbus_read_i2c_block_data ()
========================================================================================

此命令从通过
Comm 字节指定的指定寄存器读取器件的字节块。

S 地址 WR [A]通信[A]
S 地址 Rd [A][数据] A [数据] A ... [数据] NA P

功能标志：I2C_FUNC_SMBus_Read_I2C_Block


I2C 块写入：I2C_smbus_write_i2c_block_data ()
====================================================================================================================================================================================================================================================================================================================================================================================================================================================================================

与块读取命令相反、这会将字节写入
器件、写入通过
Comm 字节指定的指定寄存器。 请注意
、支持0、2或更多字节的命令长度、因为它们与数据是不可区分的。

S 地址 WR [A]通信[A]数据[A]数据[A]... [A]数据[A] P

功能标志：I2C_FUNC_SMBus_WRITE_I2C_BLOCK 

Daniel、您好！

是的、0x51命令是一个块命令。 区别在于需要在命令中指定字节数。 我在 BQStudio 中从0x51捕获了一个读取：

很抱歉造成混淆。

此致、

Matt

尊敬的 Matt：

感谢您的深入见解！

我正在为 i2c_block_read 编写一个快速 C++示例、以便根据 ManufacturerAccess 对其进行测试。

我知道 ManufacturerereAccess 和 ManufacturerBlockAccess 旨在为这些命令提供一个具有简单 i2c 读取/写入逻辑的接口。 这两种系统都提供了 i2c_read_word 和 i2c_read_block、对吧？

但是、我们一侧的误差仍然存在。 我认为 i2c 总线有问题。
您显示的5个字节对我来说是相同的、但当反复读取它们时、开始逐字节填充1s、直到所有字节为0xFF。
溢出后、一切会再次运行几秒钟。
我担心它会连接到我们正在使用的 RaspberryPi3计算模块的软 i2c。

欢迎您提出任何建议！

此致、

Daniel

Daniel、您好！

对于制造商访问命令、您可以将命令的块写入0x44、并从0x44 (或从0x23)读取块。

例如：

0x16 0x44 0x02 0x51 0x00  (将0x0051命令发送到0x44)

0x17 0x06 0x51 0x00 0x00 0x00 0x00 0x00 0x00  (读回数据、0x06为长度)

我无法再现您描述的缓冲区填充为1的问题。 我不确定是什么原因导致了这种情况。  

Matt

尊敬的 Matt：

感谢您的提示。 我们仍在调试这个问题。  
我使用不同的 i2c 库实现了多个版本。

需要记住的是 i2c 总线主控的 questoin。
TI-Tool 是创建自己的时钟还是仅创建客户端？


除此之外，您是否可以测试以下内容(? 可通过 i2cdetect -y 1/2/3)找到：

while true; do i2ctransfer -f -y ? w4@0x0? 0x44 0x02 0x51 0x00; i2ctransfer -f -y 3 r7@0x0?; done

这应该与上面显示的结果相同。
我们会得到不同的结果。

a) 0x06 0x00 0x51 0x00  0x00 0x00 0x00 0x00 0x00 ->正确
b)  0x02 0x00 0x51 0x63 0x63 0x63 0x63  ->可能寄存器未就绪
c)错误->可能从总线中否定应答、也没关系
d)  0x06 0x00 0x51 0x00  0x0F 0xFF 0xFF ->总线用0xFF 覆盖所有字节时发现的错误  

Daniel、您好！

遗憾的是、我在工作台上针对不同的器件运行了一些较长的测试。 我可以在本周晚些时候尝试测试这个。

SMBus 仅由主机计时。 BQ78350 也有一个内部系统时钟。

Matt