[参考译文] bq78PL114：周期计数返回到零

您好、Robert、

您能否澄清以下内容：

1)

您是否希望周期计数在到达客户时为1或0？

2)

这种情况发生在多少个电池组上？ 它只是其中的一部分吗？

3)

您能否在这些电池上运行另一个周期来查看周期计数器是否发生变化？

此致、

Wyatt Keller

它仅在某些电池组上、我们预计数量为1。 我们无法理解为什么它在得到一个周期后被复位为0、甚至显示了它。

您是否知道什么会导致周期计数恢复为零？

我今天做了更多的测试、发现只需更改制造商日期即可重置周期计数、并将其更改为闪存。 当 Change 刚刚被放入 RAM 中时、它不会被设定为0。 当我更改制造日期并对 RAM 进行写入待定更改时、日期会发生更改、并且我可以选择将数据压缩到闪存。 当我拔下 Batterie 并重新插入时、编辑闪存更改的选项不再存在、但它"看起来"好像所有更改都已准备就绪。

在我们的测试期间以及开始循环使用电池之前、我们会在下线测试中更改电池的制造日期。 例如，当通信中出现错误且生产日期更新但不通知 Flash 时，会发生什么情况？ 在我们循环电池后，设备本身是否有可能在稍后的线路中开始提交到闪存的过程？

您好、Robert、

器件并不总是写入闪存。 该器件将数据存储在 RAM 中、并且仅定期更新闪存。 我认为正在发生的情况是、我们没有在软件包 POR 之前留出足够的时间来更新闪存、这就是您的周期计数不会更新的原因。

感谢您的回答。 这是否意味着任何 POR 都可能会再次清除当前显示但尚未保存在闪存中的周期？

您能告诉我是否可以强制写入闪存、在这种情况下、包会执行 POR 吗？

您好、Robert、

我们正在与固件团队一起检查您是否可以让监测计执行闪存写入操作、这可能不是一种方法、但让我们检查一下。

此致、

Wyatt Keller

您好、Robert、

固件组说、在 POR 之前无法强制执行闪存写入。

如果有一个周期计数被保存到 RAM 并且器件进入 POR、那么周期计数将丢失。

此致、

Wyatt Keller

您好、Wyatt、

我们组装包装后是否应该有托尔，并且不要断开任何连接？

是否有办法在不断开电池连接的情况下强制执行 POR？

您好、Robert、

不应该有、除非在某处连接不良、导致监测计暂时断开连接。

断开电源和重新连接应该是执行上电复位的唯一方法、不过、如果监测计处于欠压状态、这是可能的。

此致、

Wyatt Keller

您好、再说一次、  

在多个测试之后、我看不到欠压情况。 电池被焊接到 PCB 上、很可能会出现连接不良的情况。 我还有一点也不对周期进行计数的包。 我将为一个具有12Ah 的"寿命已传送安培小时数"且周期计数仍然为0个周期的包附加一个文件。

在本电池组中，我将其充满电，放电直至耗尽(电池组中确实看到-2212mAh 通过电流。)  然后、我再次将其充满电、以查看我的电池组通过的电流恢复到6mAh。 我最后做的是放电至空(电池组中的-2245mAh 通过电流)。  这意味着我的总放电电容量为4457mAh。 这也反映在从8Ah 到12Ah 的寿命交付安培小时数中。 但仍然没有周期计数为1。 是否有一种无法计算周期的模式？ 我的想法已经接近尾声了、我真的需要输入或我可以检查或测试的内容、这可能会导致这种行为。 我们现在正处于这两个主要问题的某个阶段。 这些包用于 Corona 爆发的基本装备，我们不能仅仅发送行为异常或不可预测的包。  

问题：

1.周期计数上升，发送给客户时为2-3，但客户报告周期计数为0

2、即使组合输送的 Ah 远高于设计容量、周期计数也不会增加。

请您帮助我们找出导致这种行为的原因、或为我们提供支持和指导、让我们进一步测试

此致

Robert Andris

这是我写的文章的附件。 显然、它已被标记并已由管理员确认。 这是我参考的附件

e2e.ti.com/.../Export-all-Parameter.csv

您好、Robert、

您是否以与客户相同的方式读取周期计数？

这可能是一个固件问题、我们可以进一步研究。

此致、

Wyatt Keller

您好、Wyatt、

由于我们现在经常遇到此问题、因此我们已准备好从客户那里取回电池组、并确认我们以与客户相同的方式读取周期计数、并且它实际上是0。 下一个测试是我重新学习/初始化电池组、然后尝试查看计数器是否在上升。 但标志没有区别。 算法仍为启用。 请给我们一个提示、我们可以在其中进行测试、以便以某种方式对根本原因进行搜索。 现在、我没有什么可告诉客户的、除了我们正在与 TI/等待 TI 的意见来解决这个问题。  

此致、

Robert Andris

您好、Robert、

我正在等待我们的固件团队回复可能会重置周期计数的可能条件、如果重置不是由于 POR 或断电、则周期计数应提交给 DF。

自生产开始以来一直出现此问题？

此致、

Wyatt Keller

您好、Wyatt、

我们帮助另一家公司大批量生产这些包装。 该软件包实际上是在不同的站点上生产的、并且在客户公司运行了相当长的一段时间。  为了验证质量、该公司对进口货物进行了一些测试、其中一项是检查制造过程中应进行的所需周期。 由于我们生产电池组、并且在我们询问客户生产的电池是否发生此错误后、我们得知"有时"周期计数器设置为零、但在电池组制造后不会那么快。

这意味着此错误可能会持续一段时间、但通常情况下未发生或测试、与"传入商品测试"中的情况类似。

我们还有一些不能正确计算周期数的电池组。 例如、我们看到一个电池组从0Ah 变为6Ah、具有"使用寿命提供的安培小时数"、但并未增加周期数。 即使"PACK 传递电流"正在向上/向下工作、它看起来也没有计数。 我们测试了电池组、并让我对该电池组进行再记忆/初始化、在我再施加2个周期(1个仅周期的网络、大约为2200mAh、设计容量为3100)后、电池组开始计数。

在任何情况下、循环计数器的行为都是古怪的、我们可能需要一些紧急帮助来找到原因。

请告诉我们可以执行哪些测试、而不仅仅是单次循环和初始化等测试、以检查此问题的原因。

Sincerelty、

Robert Andris

您好、Robert、

我仍在等待我们固件团队的回复、下周之前应该会收到他们的回复。

我看到了这个问题、因此直到最近才对其进行监控。 这是新应用所需的功能吗？ 如果无法快速找到修复方法、您是否可以使用监测计的另一个功能来跟踪随着时间的推移而放电的电量？

您是否能够从监测计中提取安全历史数据、以查看测试过程中是否发生了任何故障？

此致、

Wyatt Keller

您好、Wyatt、

是的、直到最近才监控此问题。 是的、我们至少需要提供回收包、并通过从客户那里读取周期数来检查、我认为我们不能说服他不要使用周期计数。

我们从大多数这些电池组中提取了安全历史记录、但没有入口。 我们还进行了其他测试，发现了以下行为：

1.循环并记录的包装不会错过任何周期。 这就是为什么搜索错误如此令人沮丧的原因。

2.已循环且连接了 TI 接口适配器但未激活的电池组(可切换集线器)未正确计算周期数。 两个 SMBus 引脚均为低电平  

3.已循环并连接和激活 TI 接口适配器(可切换集线器)的数据包即使软件未记录、也已正确对周期进行计数。 两个 SMBus 引脚均为高电平

我现在有一个循环测试、在两个 SMBus 引脚上只使用一些上拉至3V3的电阻器、并将在明天获得结果。

您是否听到固件团队的反馈？  

我们从客户那里得到越来越多的压力来交付包裹、但由于很多包裹在循环过程中没有计数、因此难以满足这些数字。

此致、

Robert Andris

您好、Robert、

如果您在 TI 通信协议中未遇到此错误、则该错误可能基于通信协议或电路。

您能否使用逻辑分析仪捕获通信、捕获 bqStudio 并将其与您自己的通信进行比较、以确保它们是相同的。

您能否共享原理图、以便我们确保一切都正确？ 如果您希望设计保密、可以通过 E2E 向我发送申请。

我还在等待固件团队、他们最近非常忙、没有时间对此进行审查。

此致、

Wyatt Keller

您好、Wyatt、

当我们循环电池时、我们根本没有通信。 昨天晚上、我有2个电池组的循环、3V3连接到 SMBC、并将2个10k 电阻器连接到 SMBC 上、并且它正确计算了周期数。 在我们的公司中、我们仅使用 TI USB 接口适配器2006进行通信、因此我们实际上没有第三方通信工具。

电池是否仅在实际有设备与其通信时计数周期？ 或者至少总线上有一个高信号？

此致、

Robert Andris

您好、Robert、

EV2400在没有通信时将线路拉至高电平、我建议即使没有通信时也将线路拉至高电平。

在使用可切换集线器的第2步中、通信线路是否被拉高或悬空？ 您是否能够共享原理图？

此致、

Wyatt Keller

您好、Wyatt、  

我已通过 DM 将部分远程信息处理发送给您。 我对整个情况感到非常沮丧。 您和/或您的固件团队未向我提供正确的理由

在何种情况下、如果电池组的 FCC 值为2200mAh 左右、则在提供的安时内提供的电流为25Ah+的0个周期计数甚至是可能的。

是的、您说当有 Flash 提交或有人更改静态数据(如 SN 编号等)时、可能会将其设置回0 但当没有人改变任何东西时

正如您所说的、闪存提交非常零星、并且它们之间存在很长的时间、当我们循环那些没有通信的包10次时、SMBus 在此期间浮动时、应该有周期。  

此致、

Robert Andris