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.

[参考译文] BQ34110:MACDataLen()报告的字节

Guru**** 2614265 points
Other Parts Discussed in Thread: BQ34110

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

https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/876346/bq34110-bytes-reported-by-macdatalen

器件型号:BQ34110

我在一条 MACControl 命令之后编写代码来读取 MACData。 为了确保稳定性、我打算验证读取缓冲区的校验和。

根据 TRM:

3.25 MACDataSum():0x60
此读写函数返回当前子命令和数据块的校验和。
对该寄存器的写入提供执行需要
数据的子命令所需的校验和。 校验和的计算方式为 ManufacturerAccessControl()和
MACData()字节之和的补码。 MACDataLen()确定
校验和中包含的 MACData()的字节数。 

3.26 MACDataLen():0x61
此读写函数返回作为响应一部分并
包含在 MACDataSum()中的 MACData()的字节数。 

因此、对于一个诸如 DEVICE_NAME (0x004A)或 SECURITY_KEYS (0x0035)的控制子命令、我希望看到 MACData 加2 (制造商访问控制)中的字节数量、并使用它们来计算校验和。 但是,MACDataLen()总是比预期高两个。

例如:

在图中、第一个子命令 device_name 应返回9个字节、从0x3E 开始、但返回11 (0x0B)。 在这种情况下、由于两个额外的字节为零、因此不会影响校验和。

同样、第二个子命令 security_keys 应返回10个字节、但返回12个字节。 同样、没有问题、因为以下字节为0。

但是、上面的最后一个子命令读取0x4000上的 CC 校准数据、该数据应返回34个字节、但返回36个字节。

显然、监测计会将 MACDataLen 和 MACDataSum 中的两个字节添加到返回的数据数中。

这是预期行为吗?

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

    请查看以下应用手册。

    https://www.ti.com/lit/an/slua790/slua790.pdf

    Andy

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

    您好、Andy。

    在发布之前、我已经查看过此应用手册。 我又看了看,但我的问题找不到答案。

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

    详细阐述我的答案:

    我打算验证从 BQ34110读取的每个 CTRL 帧的校验和。 为了使软件尽可能简单、我需要读取 MACDataLen 并根据它计算校验和。 我需要知道它是否总是比有效大小大两个字节(我不相信缓冲区中的其他字节将始终为零)、所以我只需在执行校验和验证之前减去两个字节。 如果是这种情况、TI 应在 TRM 中对此进行澄清。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    请参阅我提供的应用手册第5页上的示例3。
    基本而言、读取时需要将起始寄存器设置为0x40。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    大家好、Andy、我知道所有这些 、我已经在使用它了。

    我的问题是不同的。 对于对 MACData()的每次访问,BQ34110返回 MACDataSum()和 MACDataLen()中的值,这些值允许我验证缓冲区的完整性。

    如果您看一下我在第一个帖子中的图、我发送到 BQ 的第一个子命令是 device_name (子命令0x004A)。 根据 TRM、它返回从0x40开始的7个字节、并使用字符串"BQ34110"。 它还返回在制造商访问控制寄存器(0x3E)上发送的命令、与之前发送的0x004A 相同(小端字节序格式)。 计算校验和时、将这7个字节与这2个命令字节相加、换句话说、从0x3A 开始的9个字节。 校验和位于 图中事务日志第二行的第35个字节上、值为0xE9。 如果计算每个 TRM 的校验和、则会得到该值。 我的问题是关于另一个字节、即同一行中的最后一个字节、应该是9、但应该是11 (而是0x0B)。

    我发送的其他命令重复该模式、即 MACDataLen()寄存器中的长度比预期的大两个字节。 这不是预期的行为、至少不是我在阅读 TRM 时所期望的行为、如我的第一条消息、第3.25和3.26节的引文中所示。

    为什么它很重要? 因为我想验证 BQ34110的每条消息的校验和,特别是关键消息(例如校准数据)的校验和是否稳健,我想确保我正确使用它,即使我必须从 MACDataLen()返回的值中减去两个也是如此。 我想使用这个长度值来只读取所需的字节(对于某些命令、我只需要4个字节时不需要36个字节)并使用一个 C 函数来执行它。

    我希望这一点现在更清楚。

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

    Elder、您好!

    当您从3E 进行回读时、它将包含以下内容

    0x3E/0x3F:子类 ID

    0x40:包含32字节数据

    0x60:校验和

    0x61:长度

    这是36字节、我认为它是 SMBus、而不是 I2C。 我需要仔细检查、但我希望您可以继续使用这些信息执行 C 函数读取。

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

    大家好、Kang Kang。

    是的、我知道当我读取从0x3E 开始的36个字节时、我同时拥有所有数据及其含义。

    在几种情况下(例如 DEVICE_TYPE)、返回的数据很短、我不需要读取36个字节、这会像在我的情况中那样浪费轮询系统中的时间(为了简化架构)。

    我在读取0x3E 等之前读取0x60/0x61以获得缓冲区大小、从而通过 I2C 只读取必要数量的字节、从而节省时间并允许系统的其他任务尽快工作。

    问题是从0x61读取的长度总是比我预期的长两个字节。

    但是... 我想在编写一些测试时、我找到了我的问题的答案。 具体而言、在 TRM 的第3.2.24节中:

    3.2.24 security_keys:0x0035
    <...>
    要写入密钥、请执行以下操作:
    1.将0x35 0x00写入 Control (0x00、0x01)或 ManufacturerAccessControl (0x3E、0x3F)。
    2.将大端字节序格式的数据写入 MACData (0x40–0x47)。
    3.将校验和写入 MACDataSum (0x60)。 校验和是数据
    和命令字节总和的补码。
    4.将0x08的长度写入 MACDataLen (0x61)。 长度包括命令、数据、校验和
    和和长度字节。
    

    在上面的第4步中、"长度包括命令、数据、校验和和和长度字节。" 回答我的问题、尽管是间接回答的。  因此、为了实现对称、读取数据将返回与相应写入操作所需的相同字节数、在 SECURITY_FINS 示例中、将返回12个字节(不是4中显示的0x08)。 以上)。

    IC 非常复杂复杂。 遗憾的是,文件存在一些空白,或者至少在一些基本问题上缺乏明确性。 我想知道我是否是唯一在这方面遇到这种困难的人。