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.

[参考译文] TM4C1290NCPDT:休眠模块/ WAKE 引脚行为从 TM4C123G 迁移到 TM4C1290

Guru**** 2001725 points
Other Parts Discussed in Thread: EK-TM4C1294XL, TM4C123GH6PM, TM4C1290NCPDT
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1440628/tm4c1290ncpdt-hibernation-module-wake-pin-behavior-migrating-from-tm4c123g-to-tm4c1290

器件型号:TM4C1290NCPDT
Thread 中讨论的其他器件:TM4C123GH6PM、EK-TM4C1294XL

工具与软件:

我们以前使用 TM4C123GH6PM 实施了一个设计、现在我们要将它迁移到 TM4C1290NCPDT。  

在我们的系统中、休眠模块通过使用其/HIB 输出禁用稳压器来为电路供电。  该代码指示系统根据命令进入休眠状态、并且可以通过计时器或/WAKE 引脚将其唤醒。  /WAKE 引脚上拉到纽扣电池、上面以1M 的上拉电阻为休眠模块(VBAT)供电。  我知道这是一个非常弱的上拉电阻、但是我们进行的操作功耗非常低、并且试图节省电池电量。  系统还可以在串行 Rx 上唤醒、因为/WAKE 被 MOSFET 电路拉至接地(栅极上具有 Rx)。

以下屏幕截图显示了使用 TM4C123GH6PM 时的预期行为。  Ch1 (黄色)= VBAT (纽扣电池)、Ch2 (蓝色)=/WAKE、Ch3 (粉色)=/HIB、Ch4 (绿色)=处理器的3.3V 主电源。

由于/WAKE 连接到 Rx、因此  可以在/WAKE 行中看到进入休眠状态的命令。  大约250ms 后、/HIB 变为低电平、然后主电源在稳压器被禁用时消失。

在 TM4C1290上、同样的行为如下所示:

系统 进入休眠状态后会立即唤醒。

放大/HIB 变为低电平时的行为(关闭稳压器)、

似乎/WAKE 线正在萎缩。 我想知道 TM4C129内部某个位置、/WAKE 是否会受主电源影响、因为我知道  在唤醒时休眠模块的主电源接管行为发生了一些变化。

尽管这对于我们的电流消耗来说并不理想、但我加强了/WAKE 线路上的上拉电阻。  使用10k 上拉而不是1M、我得到了以下波形:

(使用100k 上拉电阻时也出现了一些不同的奇怪行为、但上面的波形 更清楚地表明/WAKE 引脚上的骤降可能不是导致系统唤醒的原因。)

我在这个电路中确实有一个版本、在这个版本中、稳压器不会被/HIB 禁用、所以即使在系统休眠后、主电源仍然存在。  这在其他几个方面也有所不同(例如在 Rx 上没有唤醒)。  此版本正常休眠、并且在/WAKE 上没有骤降、即使在1M 上拉时也是如此。  但是、它的不同之 处对我来说都不是一种能够带来不同的东西。   由于受主电源影响而使/WAKE 下降到阈值以下的想法似乎被上述示波器轨迹所驳斥(此外、它甚至从未达到 如此低的水平)。

我正在寻找有关什么原因可能会导致我们的系统在休眠后立即唤醒的想法。  我不确定/WAKE 线的行为是否线索、但我更愿意使用我可以节省电力的最弱上拉电阻。  休眠模块的电路和代码应 与可正常工作的 TM4C123板基本相同。  我浏览了 TM4C123和 TM4C129之间的一些差异、当我这样做时、例如将一些可配置为 Wake (唤醒)的 GPIO 接地、不应在软件中将其配置为用作/WAKE。   

谢谢!

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

    为了获得更多线索、时钟在休眠过程中不保持不变;在睡眠唤醒事件后复位。  我已经探测了 uC 上的 VBAT 引脚并确认它已通电。  我们在 XOSC0上使用外部振荡器、这与我们工作的 TM4C123板相同。

    该代码会检查唤醒原因。  根据我的理解(我没有编写代码)、由于 MAP_HibernateIsActive ()(休眠 API 的宏)为 False、唤醒的原因被标识为 POR。  在我看来、存在一些软件问题、使得应该通过休眠来维护的内容(例如时钟、配置?) 不是。  在 TM4C123和 TM4C129上、我们设置休眠模块的方法是否存在差异?  我在比较数据表时没有发现任何差异。

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

    您好!

     -您可以在 EK-TM4C1294XL LaunchPad 上重现问题(使用现有代码)吗?

     -您可以通过在以下位置运行 TM4C129休眠示例来重现问题:

    C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\HIBERNATE

    C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\HIBERNATE_Calendar

     通过在 LaunchPad 上运行您的代码以及定制电路板上现有的 TivaWare 休眠示例、我希望您可以找到有关发生什么的一些线索。  

     

     另请参阅 TM4C129、了解休眠模式的基准电路。  

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

    尊敬的 Charles:

    感谢您的建议。  我首先尝试让 TM4C129休眠示例与我们的硬件协同工作。

    经过一些修改以适应差异(例如不同的系统晶体)后、HIBERNATE_Calendar 大多数是能够工作的。  当休眠时、纽扣电池以寄生方式为主电源供电、但我怀疑这可能是由于 Launchpad 上的一些功能在代码中实现了、但我没有移除。  

    在休眠示例中、问题更多。  行为不一致、似乎可能取决于先前加载的代码。  我想知道这个示例是否缺少对 HibernateWakeSet ()的调用。  我找到了 ROM User's Guide (ROM 用户指南)、其中说明在调用 HibernateRequest ()之前、必须使用 HibernateWakeSet ()配置唤醒源。  我在 Tivaware 2.2.0.295版本的 TM4C1294XL 休眠示例中未找到对 HibernateWakeSet ()的调用。  我的例子直到我调用 HibernateWakeSet ()添加 RTC 作为唤醒源后才开始睡眠。

    在添加对 HibernateWakeSet ()的调用后,该示例处于睡眠和唤醒状态,但仍然无法正常工作,因为中断函数中对 HibernateIntStatus ()的调用没有返回正确的值。  根据我的理解、该函数返回一个指示中断源的标志。  在我的代码中、HibernateIntStatus (0)作为整数的原始返回值为16 (我也看到过17次、但这种情况非常令人困惑)。 我在一些文档中发现 HIBERNATE_INT_RTC_MATCH_0标志 将为 0x1、HIBERNATE_INT_WR_COMPLETE 是值为0x10的 HIBERNATE_INT 标志。  

    尽管我不确定自己 是否正确解释了所有内容、但实际上我  之前已经看到过 HIBERNATE_INT_WR_COMPLETE 标志。  它在我们自己的代码中显示为唤醒原因(休眠后立即唤醒)。  我们对它有点困惑、然后它 从代码中写出了。  我找不到有关此唤醒源的含义或它显示时的文档。  你有更多关于这个标志的信息吗?

    关于电路、我还注意到、器件工作表中紧接您发布的电路之后出现了使用专用振荡器的电路(我们的用例)、该电路具有1M 的上拉电阻。  因此、我想我们的1M 上拉电阻也应该没问题。

    我实际上发现了 另一篇 E2E 文章、该文章似乎具有类似的问题、但我在此主题中未看到解决方案。

    我会继续尝试将我们的代码与工作中的 HIBERNATE_Calendar 代码进行比较、不过、如果您有关于 HIBERNATE_INT_WR_COMPLETE   标志的任何信息 、或者有任何其他想法、请告诉我。  谢谢!

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

    尊敬的 Irene:

    我将继续尝试将我们的代码与工作中的 HIBERNATE_Calendar 代码进行比较、

    您有更新吗?

    如果您有关于 HIBERNATE_INT_WR_COMPLETE   标志的 任何信息或任何其他想法、请告诉我。

    很抱歉这么晚才回复。 这是为了在休眠模块准备好从 CPU 进行写入访问时启用中断、因为 CPU 和休眠模块不会相互同步、因为它们位于不同的时钟域。  

    寄存器访问时序
    因为休眠模块具有独立的时钟域、所以休眠寄存器必须
    只能在两次访问之间有一个时间间隙时写入。 因此、延迟时间为 tHIB_REG_ACCESS
    软件必须保证这个延时时间不会连续写入休眠寄存器
    或先后在写入和读取之间进行读取。 可以使用 HIBMIS 寄存器中的 WC 中断
    用于通知应用程序何时可以访问休眠模块寄存器。 或者、
    软件可以利用休眠控制(HIBCTL)寄存器的 WRC 位来确保这一点
    所需的时序间隙已过去。 该位在写操作时被清零、在写操作后被置位
    完成、向软件指示可以安全地开始另一个写入或读取操作。 软件应该支持
    访问任何休眠寄存器之前、应轮询 HIBCTL 以了解 WRC 是否为1。

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

    尊敬的 Charles:

    感谢您提供的信息。  我的同事 提出了一个解决办法、似乎解决了我们的问题。  (我仍然无法让休眠示例正常工作、因此与我们的硬件配合使用时、休眠示例可能会出现一系列不同的问题、但我们能否解决主要问题实际上并不重要)。

    我的同事说:  

    Tivaware 的 HibernateWakeSet 出错、会打开 HIB_CTL_VDD3ON。 我敢打赌、如果该位已设置且 VDD 失败(因为我们将其关闭)、那么它会触发 HIB 复位、就像 POR 复位一样。 或者可能我们的 一些东西掉电、因为当 VDD3ON 被置位时、GPIO 仍然可以提供一些电流。 不确定。

    该错误位于 HIBERNATE.c 第453行、它尝试测试 ui32WakeFlags 是否设置为 HIBERNATE_WAKE_RESET 或 HIBERNATE_WAKE_GPIO 、但由于它执行按位而不是按值、如果设置了 HIBERNATE_WAKE_PIN 、它会错误地解析为 TRUE、因此它会启用 HIB_CTL_VDD3ON、因为 HIB_CTL_VDD3ON 是 HIBERNATE_RESET (基于 HIBERNATE_WAKE_RESET)。

    以下是他所引用的 Tivaware Hibernate.c 中的函数:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    //*****************************************************************************
    //
    //! Configures the wake conditions for the Hibernation module.
    //!
    //! \param ui32WakeFlags specifies which conditions should be used for waking.
    //!
    //! This function enables the conditions under which the Hibernation module
    //! wakes. The \e ui32WakeFlags parameter is the logical OR of any combination
    //! of the following:
    //!
    //! - \b HIBERNATE_WAKE_PIN - wake when the external wake pin is asserted.
    //! - \b HIBERNATE_WAKE_RTC - wake when the RTC match occurs.
    //! - \b HIBERNATE_WAKE_LOW_BAT - wake from hibernate due to a low-battery
    //! level being detected.
    //! - \b HIBERNATE_WAKE_GPIO - wake when a GPIO pin is asserted.
    //! - \b HIBERNATE_WAKE_RESET - wake when a reset pin is asserted.
    //!
    //! If the \b HIBERNATE_WAKE_GPIO flag is set, then one of the GPIO
    //! configuration functions GPIOPinTypeWakeHigh() or GPIOPinTypeWakeLow() must
    //! be called to properly configure and enable a GPIO as a wake source for
    //! hibernation.
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    他编写了自己的函数,该函数被调用来代替 HibernateWakeSet()。  为了帮助任何其他人解决这个问题、我会在这里发布(请注意、我们的唤醒源是 RTC 和 WAKE 引脚)。

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    void wait_for_hib_wrc()
    {
    while(!(HWREG(HIB_CTL) & HIB_CTL_WRC))
    {
    }
    }
    // wake_flags may be bit-or of HIB_CTL_RTCWEN, HIB_CTL_PINWEN, HIB_CTL_BATWKEN
    void hib_set_wake_source(const uint32_t wake_flags)
    {
    uint32_t wake_mask = 0;
    uint32_t temp = 0;
    wake_mask = HIB_CTL_RTCWEN | HIB_CTL_PINWEN | HIB_CTL_BATWKEN;
    temp = HWREG(HIB_CTL);
    temp &= (~wake_mask);
    temp |= (wake_flags & wake_mask);
    HWREG(HIB_CTL) = temp;
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

     用这个新函数替换对 MAP_HibernateWakeSet ()的调用后,我们的主板可以正常休眠。

    感谢您对此的帮助、

    Irene.