[参考译文] CC2538：电源模式2问题

您好、您好、我

当睡眠定时器溢出时、它将从零开始重新计数。  鉴于未提供任何意外的 ui32Diff 值、我看不到错过捕捉事件的原因。  唯一的考虑因素是 Sleep ModeTimerCompareSet 是否需要花费更长的时间等待通过 ST3寄存器写入 ST0。

空
睡眠模式定时器比较集(uint32_t ui32Compare)
｛
//
//等待 st0、st3寄存器准备好写入
//
while (！(HWREG (SMWDTHROSC_STLOAD)& SMWDTHROSC_STLOAD_STLOAD))
{
}

HWREG (SMWDTHROSC_ST3)=(ui32Compare >> 24)& 0x000000ff；
HWREG (SMWDTHROSC_ST2)=(ui32Compare >> 16)& 0x000000ff；
HWREG (SMWDTHROSC_ST1)=(ui32Compare >> 8)& 0x000000ff；
HWREG (SMWDTHROSC_ST0)= ui32Compare & 0x000000ff；
｝ 

此问题的发生频率如何、并且通过使用更大的毫秒值来缓解此问题？  这在 SMARTRF06EBK 等 TI 硬件上是否可以观察到？

此致、
Ryan

您好、Ryan、

非常感谢。  我将与客户进行核实。

此致、

请

您好、Ryan、

我们与客户进行了检查、系统每20ms 进入 PM2一次。 16个器件中有3个存在此问题、我们不知道是否可以在评估板上重现此问题。

我认为这是一个硬件因素、因为它仅发生在某些产品上。

我们将检查电源电压和时钟并返回给您。

此致、

请

您好、Ryan、

感谢你的答复。 这是在大规模生产运输过程中发现的一个非常紧迫的问题。 如果问题未得到解决、我将在此提出请求。

我们将检查硬件、也将检查软件。 我们认为，这个问题的因素是：

・电源和时钟的设计错误、影响 CC2538和时钟。
->现在我们确认。
・尚未应用勘误表的权变措施。
・不适当的值存储在比较值中。
->现在，我们正在检查计时器，并比较从睡眠状态恢复时的值。
->在不从睡眠状态恢复时检查故障处理程序寄存器。

我对此有一些疑问。

问题1：
关于基础固件中的"SysCtrlDeepSlep" API。 (driverlib 中的 sys_ctrl.c)和勘误表。
是否在 API 中实现了权变措施？  我认为它适用、但难以理解描述。

勘误表：1.5 PM2和 PM3之后时钟分频器的值可能不正确

void
SysCtrlDeepSleep (void)
｛
#ifndef no_clock_divider _restore
bool bRestoreSys；
bool bRestoreIO；
uint32_t ui32Reg；

ui32Reg = HWREG (SYS_CTRL_CLOCK _STA)；
bRestoreSys =(ui32Reg & SYS_CTRL_CLOCK _STA_SYS_DIV_M)==0；
bRestoreIO =(ui32Reg & SYS_CTRL_CLOCK _STA_IO_DIV_M)==0；
if (bRestoreSys || bRestoreIO)
｛
ui32Reg = HWREG (SYS_CTRL_CLOCK _CTRL)；
ui32Reg |= bRestoreSys? 0x1：0x0；
ui32Reg |= bRestoreIO？ 0x100：0x0；
HWREG (SYS_CTRL_CLOCK _CTRL)= ui32Reg；
｝
#endif

//
//启用深度睡眠。
//
HWREG (NVIC_SYS_CTRL)|= NVIC_SYS_CTRL_SLEEPDEEP；

//
//等待中断。
//
CPUwfi()；

//
//禁用深度睡眠，以便将来的睡眠正常工作。
//
HWREG (NVIC_SYS_CTRL)&=~(NVIC_SYS_CTRL_SLEEPDEEP)；

#ifndef NO_CLOCK_DIVIDER_RESTORE
if (bRestoreSys || bRestoreIO)
｛
ui32Reg = HWREG (SYS_CTRL_CLOCK _CTRL)；
ui32Reg &= bRestoreSys？ ~SYS_CTRL_CLOCK CTRL_SYS_DIV_M：0xFFFF；
ui32Reg &= bRestoreIO？ ~SYS_CTRL_CLOCK CTRL_IO_DIV_M：0xffffff;
HWREG (SYS_CTRL_CLOCK _CTRL)= ui32Reg；
｝
#endif
｝ 

问题2：
如果软件是一个因素、则定时器计数可能会在它被置位前超过比较值。
关于基础固件示例(睡眠模式)、睡眠模式 TimerCompareSet 设置为10000之后。

ui32Val = SlepModeTimerCountGet ()；
SlepModeTimerCompareSet (ui32Val + 10000)； 

您知道在 cc2538进入睡眠模式之前可以设置的最小比较值数吗？

感谢你的帮助。

此致、
请

Q1： 只要 未定义 NO_CLOCK_DEEP_RESTORE、SysCtrlDeepSleep API 就会应用勘误表1.5的权变措施。

Q2：您已经在用户指南中记录了这一点："设置新的比较值时、该值必须至少比当前睡眠定时器值多5个。"  您似乎正在使用几百微分的值、这应该是可以接受的。

此致、
Ryan

您好、Ryan、

非常感谢。 目前、客户正在尝试不同的设置。 当它们禁用"32kHz RCOSC 校准"时、问题不再出现。 他们希望在不进行校准的情况下使用32kHz 内部振荡器。

禁用校准后、32kHz RC 振荡器的精度是多少？
我知道 DS 中的校准精度为5.10 32kHz RC 振荡器。

此致、
请

32kHz RC 振荡器在 未经校准时非常不准确、并且随温度和电源电压变化而变化很大。  不建议运行、因此数据表中未指定。   由于校准后的32kHz RC 振荡器频率是32MHz XTAL 频率除以977、因此请确保该外部晶振正常工作。

此致、
Ryan

您好、Ryan、

感谢你的答复。 我们已经检查了时钟。 它们使用与 CC2538EMK 相同的晶体和电容。
因此、我们认为原因是其他原因、但我将联系"设计审查"。

顺便说一下、我们已经试验并发现、如果我们不对其进行校准、它会从 PM2中唤醒、这很好。 如果客户的应用不需要32kHz RC 振荡器的精度、我们希望在不进行校准的情况下使用它。 我假设32kHz RC 振荡器仅提供给睡眠定时器、WDT 和 MAC 定时器。 是这样吗？

很抱歉、我想问一些这么小的问题、我每天都很感谢您的支持。

此致、
请

您对低频振荡器使用情况的分析是准确的、 TRM 的第7.2.2节对此进行了进一步说明。

此致、
Ryan

您好、Ryan、

非常感谢你的帮助。 我们还将考虑在禁用校准的情况下使用它。
现在、我们将研究不从 PM2唤醒的机制。 因此、客户对其使用有疑问。

1. CC2538上电
2.有源模式500ms (32MHz 外部晶振和32kHz 内部振荡器)
电源模式2：20ms
活动模式：1ms
电源模式2：20ms
6.工作模式：1ms
7.重复3~6

启用校准。 32kHz RCOSC 校准被规定为需要2ms。
TRM：7.2.2.1 32kHz RCOSC 校准

在其使用中、活动模式仅为1ms。 每次切换至32MHz XOSC 时进行校准。 换言之、它每次从 PM2唤醒时都会进行校准。 是这样吗？

如果工作模式仅为1ms、校准可能无法完成。 根据 TRM、当 WFI 在校准完成前置位时、它在转换至 PM2期间进行校准。 因此、我们认为到 PM2的转换时间将更长、并且在转换期间将超过比较值。

此致、
请

正确的做法是、每次 MCU 唤醒时都会进行校准、并且可以延长可变转换时间以完成校准、 但我不理解额外2ms 的转换会如何导致20ms 后从 PM2唤醒的丢失。  校准需要比估计的时间长很多才能导致问题。  如果您在进入 PM2之前添加一个小的(几 ms)延迟或者延长在 PM2中花费的时间、会出现什么情况？

此致、
Ryan

您好、Ryan、

非常感谢。 我们已经对其进行了测试。 当我们设置3ms 活动时间时、问题不会出现。 (需要更多实验)当 PM2设置为1ms 时、问题频率会增加。

我还认为20ms 是足够的校准时间、但它有问题。 因此、讨论的重点将是设计外部32MHz 时钟和校准时间。 客户不希望32kHz 振荡器具有如此高的精度、因为他们只使用了睡眠定时器和 WDT。 因此、客户正在考虑在禁用校准的情况下使用它。

问题1：
例如、我们在启动时进行一次校准、然后禁用校准。
校准后的状态是否会保持？

问题2：
我们正在考虑定期启用校准(例如、每小时一次)。
此用法是否正常？

问题3：
我们正在检查数据表。
5.8 32MHz 晶体振荡器
断电保护时间：最小3ms

这一次意味着什么？ 这是否意味着断电时间(PM2时间)需要超过3ms 才能再次振荡？ 感谢您在另一个线程中的支持。 我们还考虑使用外部32kHz 晶体。

此致、

请

您好 Rei、

您对断电保护时间的解释是正确的。 遗憾的是 、我们需要对校准频率和寿命进行更多研究。 我在内部询问这一点、但这是一个较旧的器件、因此可能需要更长的时间。 希望很快得到答案。

最棒的

您好、Nathan、

感谢您的回答。  我期待您的答复。

此致、

请

您好、Ryan、

感谢您的检查。 现在、客户希望在不进行校准的情况下使用 cc2538并解决此问题。
评估后、他们认为这种使用不会引起任何问题、但他们想知道这个问题的机制。 我们假设这个问题。

e2e.ti.com/.../e2e.pdf

如果还有其他可能的因素、请告诉我。
我将继续期待您对校准的回应。(问题1和2)

非常感谢您的支持。

此致、
请

感谢您提供详细的摘要 Rei。  我相信校准状态将会保持、并且鉴于温度和电压漂移不是问题、定期重新校准将会很好、但我不确定这一点、并且仍在等待其他专家确认。

此致、
Ryan

您好、Ryan、

非常感谢。 您的信息将会保存我们。
借助您的信息、我们将更接近解决方案、但客户仍有疑问。

当我们在没有校准的情况下使用它时、波动很大。 我的客户将在一段时间内校准一次、但他们不知道应该保持多少时间。

问题1：
CC2538数据表5.10 32kHz RC 振荡器
校准时间典型值为2ms
您是否有关于最大校准时间的任何信息？

问题2：
他们希望检测32kHz RC 振荡器校准已完成。 您会告诉我如何检测它吗？

问题3：
在用户指南的第7.2.2.1节32kHz RCOSC 校准中、
「校准期间、使用32 MHzXOSC 的分频版本。 校准的结果是32kHz RSOSC 以32.753kHz 的频率运行。」μ A

换句话说、
・校准期间、使用32MHz XOSC 的分频版本。
・睡眠期间、它使用校准后的32kHz RC 振荡器。

当校准在激活期间完成时、使用哪一个32kHz 时钟？
32MHz XOSC 的分频版本"或"校准的32kHz RC 振荡器"

客户正在使用 piinmux 输出并观察32kHz 波形。 32kHz 时钟的占空比在激活和 PM2之间是不同的。 通过观察这一点、我们可能知道校准何时完成。

此致、
请

您好！

对于 Q3、我们可能已经用我们的实验解决了这个问题。

我们尝试增加活动时间；在活动模式下大约1.6ms 后、我发现32kHz 占空比变化的时序。 这个时序将表明32kHz 时钟已经被切换。 校准后表示使用了"经校准的32kHz RC 振荡器"。

如果您对 Q1和 Q2有任何信息、请告诉我。

此致、

请

您好、Ryan、

您对 Q1和 Q2有任何信息吗？
如果有任何答复，我将不胜感激。

此致、

请

您好 Rei、

遗憾的是、我们没有该部件的最大校准时间。

2.我认为您可以使用32kHz 时钟作为计时器的时钟源、以计数到1.6或2ms 或您决定用作截止频率的任何值。  不过、您需要考虑+/-18%的精度、因此要考虑预期的2毫秒延迟、您需要等待至少2.36 = 2 * 1.18毫秒、以确保在最坏的情况下仍能正常工作。

最棒的

不需要

您好、Nathan、

非常感谢您的支持。 很抱歉、我无法理解 Q2。
我们从实验中得知、32kHz 时钟源在校准完成后进行切换。

我们认为每个单独器件的校准时间(大约1.6ms、排印错误2ms)会有所不同。 如果我们可以在时钟源发生变化时检测到它、我们可以确认它并进入 PM2。

是否可以检测校准已完成？ 例如、查看寄存器。

此致、

请

REI、

唯一的时钟源变化是 从16MHz RC 振荡器变为32MHz 晶体振荡器退出 LPM 后、完成校准所需的时间为~2ms。  没有可用于确定校准完成的确切时间的寄存器。  如 Nathan 所述、在激活模式下、您需要等待最大2.36ms、以确保校准完全执行。

此致、
Ryan

Ryan、Nathan、

非常感谢。 我了解到它无法检测校准已完成。

再次感谢您的支持。 我会随时向您发布。

此致、

请