diff --git a/docs/Application_guide/zh/media/system/power-manager/Charger_example.png b/docs/Application_guide/zh/media/system/power-manager/Charger_example.png new file mode 100644 index 0000000000000000000000000000000000000000..cd15bc1317600776948f1cec4c57f972af4c5bdf Binary files /dev/null and b/docs/Application_guide/zh/media/system/power-manager/Charger_example.png differ diff --git a/docs/Application_guide/zh/media/system/power-manager/PMIC_CPU_Hardware.png b/docs/Application_guide/zh/media/system/power-manager/PMIC_CPU_Hardware.png new file mode 100644 index 0000000000000000000000000000000000000000..ca5b36d36ca20b87205e0da0136186411ecf6ee2 Binary files /dev/null and b/docs/Application_guide/zh/media/system/power-manager/PMIC_CPU_Hardware.png differ diff --git a/docs/Application_guide/zh/media/system/power-manager/PMIC_example.png b/docs/Application_guide/zh/media/system/power-manager/PMIC_example.png new file mode 100644 index 0000000000000000000000000000000000000000..63b8ce14c7d81604be6ea73d6d2563972e5d6bb1 Binary files /dev/null and b/docs/Application_guide/zh/media/system/power-manager/PMIC_example.png differ diff --git a/docs/Application_guide/zh/media/system/power-manager/PowerkeyOn.png b/docs/Application_guide/zh/media/system/power-manager/PowerkeyOn.png index 4a010eb57b849f38260b541f87e8a87070e7065f..becc9e63d7377ac2a959e9a86969032bf4c6a2fa 100644 Binary files a/docs/Application_guide/zh/media/system/power-manager/PowerkeyOn.png and b/docs/Application_guide/zh/media/system/power-manager/PowerkeyOn.png differ diff --git a/docs/Application_guide/zh/media/system/power-manager/Powerkeyoff.png b/docs/Application_guide/zh/media/system/power-manager/Powerkeyoff.png index f3fbe678c66c29b78d5dd85523932a798f3f6374..2524340f5a9a7825b7b124988e1078775400d5b7 100644 Binary files a/docs/Application_guide/zh/media/system/power-manager/Powerkeyoff.png and b/docs/Application_guide/zh/media/system/power-manager/Powerkeyoff.png differ diff --git a/docs/Application_guide/zh/media/system/power-manager/Reset.png b/docs/Application_guide/zh/media/system/power-manager/Reset.png index 36dd1aaf7264850b74c90c2446191b01b73aa1a2..2e817cf77c4849956c231034b6966133e4f61ca7 100644 Binary files a/docs/Application_guide/zh/media/system/power-manager/Reset.png and b/docs/Application_guide/zh/media/system/power-manager/Reset.png differ diff --git a/docs/Application_guide/zh/media/system/power-manager/USB_BOOTTime.png b/docs/Application_guide/zh/media/system/power-manager/USB_BOOTTime.png index c3b440f297072c4372e0e60428012303e2d04298..869d3522ae1c546e188118402850f797f21236bd 100644 Binary files a/docs/Application_guide/zh/media/system/power-manager/USB_BOOTTime.png and b/docs/Application_guide/zh/media/system/power-manager/USB_BOOTTime.png differ diff --git a/docs/Application_guide/zh/media/system/power-manager/VDD_EXTTime.png b/docs/Application_guide/zh/media/system/power-manager/VDD_EXTTime.png index 8de2c783ef56c6e4b11cb738bff3cac054c17e4d..f129e4df2a8831b96fbf8e75b8b30341d066eb3f 100644 Binary files a/docs/Application_guide/zh/media/system/power-manager/VDD_EXTTime.png and b/docs/Application_guide/zh/media/system/power-manager/VDD_EXTTime.png differ diff --git a/docs/Application_guide/zh/media/system/power-manager/autostart.png b/docs/Application_guide/zh/media/system/power-manager/autostart.png index 6323e42022a9b221aa949bfbbf1236cc1be7a54d..4291567ae76812ab5599468e0cf761a7589d338b 100644 Binary files a/docs/Application_guide/zh/media/system/power-manager/autostart.png and b/docs/Application_guide/zh/media/system/power-manager/autostart.png differ diff --git a/docs/Application_guide/zh/media/system/power-manager/soc_example.png b/docs/Application_guide/zh/media/system/power-manager/soc_example.png new file mode 100644 index 0000000000000000000000000000000000000000..216ef06d4dbc8e39942e7001a38cb654fd6c175b Binary files /dev/null and b/docs/Application_guide/zh/media/system/power-manager/soc_example.png differ diff --git a/docs/Application_guide/zh/media/system/power-manager/soc_power.png b/docs/Application_guide/zh/media/system/power-manager/soc_power.png new file mode 100644 index 0000000000000000000000000000000000000000..fc16213978aaf4a5d86163087b84a8d6e5797744 Binary files /dev/null and b/docs/Application_guide/zh/media/system/power-manager/soc_power.png differ diff --git a/docs/Application_guide/zh/system/power-manager.md b/docs/Application_guide/zh/system/power-manager.md index e9cb0257dc93ba334f762a87735450c6769ff817..72db8810e1d4ab6629f34fa04dc3c91827248231 100644 --- a/docs/Application_guide/zh/system/power-manager.md +++ b/docs/Application_guide/zh/system/power-manager.md @@ -2,252 +2,328 @@ ## 1.电源管理概述 -为什么要进行电源管理： -节能和延长电池寿命：可以根据不同的应用场景和负载要求，实现电源的高效管理和控制。例如，可以通过动态调整电源电压和电流等参数，来适应不同的负载要求，从而提高电池使用效率和寿命。 -保护系统安全和稳定性：可以监测电池电量、电源温度、电压和电流等关键参数，以保证系统的安全和稳定性。例如，在电池电量过低或过高、电流过大或过小等情况下，电源管理IC芯片会自动控制和保护电源系统，防止系统因电源问题而损坏或出现故障。 -提供多种功能和接口：如ADC、CODEC、PWM、温度监测、LED驱动、RTC等，可以为不同的应用提供灵活和多样化的电源管理解决方案。 -提高系统效率和性能：通过使用高效的DC-DC转换器和低功耗的睡眠模式等技术，可以减少系统的能量损耗和功耗，从而提高系统的效率和性能。 +随着SOC技术的发展，电源管理技术也在不断革新。现今的SOC一般采用PMU（Power Management Unit，电源管理单元）来进行供电，其设计目标一般包括以下几点： -### 1.1 电源管理芯片(PMIC) -PMIC是power management IC的缩写，中文是电源管理集成电路，主要特点是高集成度，将传统的多路输出电源封装在一颗芯片内，使得多电源应用场景高效率更高，体积更小。蜂窝模组为了在减小体积同时实现多电源，大量采用PMIC。 +**多档电源的需求：**如下图，SOC往往包含了不同功能和电压域的IP。随着SOC越来越复杂，包含的IP越来越多，单个SOC上实现了CPU, 射频模块，相机模块，DDR控制模块，外设等等功能。多种功能，多种IP也带来了多档电源的需求。同时为了满足低功耗的需求，SOC通常被分为多个电源域，不同的电源域可以独立的上下电，从而实现更灵活的功耗控制。 -### 1.2 电源管理单元（PMU） -PMU就是电源管理单元，一种高集成的、针对便携式应用的电源管理方案。将传统分立的若干类电源管理芯片，如低压差线性稳压器(LDO)、直流直流转换器(DC/DC)等集成到电源管理单元(PMU)中。 -这样可实现更高的电源转换效率和更低功耗，及更少的组件数以适应缩小的板级空间，成本更低。 -很多地方，PMU等同于PMIC，但是这里讨论的SOC外部的供电芯片是PMIC, SOC内部的电源管理单元被称为PMU。 - +**典型SOC架构示意图：** -### 1.3 DC_DC +![soc_example](../media/system/power-manager/soc_example.png) -DC_DC指直流转直流电路，广义上包括所有输入输出都是直流的电源，下文将要提到的LDO，也是一种DC_DC。这里我们所说的DC_DC实际上指的是DC_DC最典型的一种实现形式：开关恒流源。 +**节能和延长电池寿命：**可以根据不同的应用场景和负载要求，实现电源的高效管理和控制。例如，可以通过动态调整电源电压和电流等参数，来适应不同的负载要求，从而提高电池使用效率和寿命。 -蜂窝基带的DC_DC一般都是BUCK电路，根据用途的不同会附带一些特殊功能，例如： -DVC_BUCK_DC/DC电路给CPU供电：负载能力强，带DVC（动态调节电压）功能，允许动态调整电压，达到节能目的。 -APT_BUCK_DC/DC电路给射频以及PA供电：负载能力强，带APT（平均功率追踪）功能，减少射频耗电。 +**保护系统安全和稳定性：**可以监测电池电量、电源温度、电压和电流等关键参数，以保证系统的安全和稳定性。例如，在电池电量过低或过高、电流过大或过小等情况下，电源管理IC芯片会自动控制和保护电源系统，防止系统因电源问题而损坏或出现故障。 -从用途上可以很明显看出来，DC_DC的优势是负载大。除了负载，它还有输入范围宽、转换效率高的优点。相对于LDO，它的缺点是结构复杂，负载响应差，纹波较大，不适合给对噪声敏感的电路供电。 - +**提供多种功能和接口：**除了基础的电源管理功能之外，PMU往往集成了一些其它功能，如ADC、CODEC、PWM、温度监测、LED驱动、RTC等。这些功能可以配合PMIC本身的电源管理，为不同的应用提供灵活和多样化的电源管理解决方案；亦可以通过通讯接口和CPU交互，丰富SOC的功能。 -### 1.4 LDO +**提高系统效率和性能：**通过使用高效的DC-DC转换器和低功耗的睡眠模式等技术，可以减少系统的能量损耗和功耗，从而提高系统的效率和性能。 + + +典型的SOC芯片供电系统和内部电源管理单元如下图所示： + +![soc_power](../media/system/power-manager/soc_power.png) + +如图可见，典型SOC的供电系统中，powerkey同时给功能不同的IP核进行供电，同时进行兼顾开机和充电的管理。PMIC除了电源的输入/输出之外，往往还集成了时钟电路、RTC电路、多种模拟IP（一般ADC和温度传感器比较多见，部分PMIC内集成了音频CODEC）。PMIC是如何利用自身的多种功能进行电源管理呢？以下章节我们由PMIC入手，介绍其组成以及电源管理的实现。 + + +## 2. PMU 简介 + +PMU就是电源管理单元，一种高集成的、针对便携式应用的电源管理方案，即将传统分立的若干类电源管理芯片，如低压差线性稳压器(LDO)、直流直流转换器(DC/DC)，但现在它们都被集成到手机的电源管理单元(PMU)中，这样可实现更高的电源转换效率和更低功耗，及更少的组件数以适应缩小的板级空间，成本更低。 + + +**SoC处理器的PMU一般需求以下特性：** + +**1.多档电源：**需要外部电源芯片提供多档电源，或在某档电源上施加较高的电流。原因在于SoC处理器通常要求其核心、I/O设备和存储单元等独立供电，而这些单元对电压、电流、频率等的要求通常各不相同。 + +**2.状态控制：**对外部提供专用控制信号，通过PMU控制寄存器设定这些控制信号的状态，从而实现对SOC整体电源状态的控制。PMU的一些基本接口信号（如系统开机、系统复位、电源状态指示信号等）发生变化后，SOC处理器状态将随之改变。 + +PMU由内部DC／DC和PMu寄存器等构成，PMU为SOC的处理器，PLL, DDR, 图像单元等供电。同时，PMU也利用电源管理总线(PMBus)控制外部供电系统。 + +PMU一些基本功能如下： + +1.控制开关机，上电下电的时序 +2.LDO&DCDC 开关控制 +3.CPU 电压&主频调节 +4.高温保护功能 +5.模拟输入ADC +6.GPIO 功能 +7.充电功能 +8.RTC +9.看门狗 +10.codec +11.低功耗管理 + +不同SOC的PMU可以实现的功能不同，上述功能中控制开关机、高温保护、GPIO、充电管理、RTC、低功耗管理功能和用户相关性较强，后续章节我们重点介绍，其中低功耗将由专门的章节([power-consumption](power-consumption.md))来介绍。 + +## 3.名词解释 + +在正式介绍PMIC的功能之前，我们先来了解一些电源管理中常用的功能或技术： + +**1.电源管理芯片(PMIC)** +   PMIC是power management IC的缩写，中文是电源管理集成电路，主要特点是高集成度，将传统的多路输出电源封装在一颗芯片内，使得多电源应用场景高效率更高，体积更小。 + +**2.电源管理单元(PMU)** +   PMU就是电源管理单元，一种高集成的、针对便携式应用的电源管理方案。将传统分立的若干类电源管理芯片，如低压差线性稳压器(LDO)、直流直流转换器(DC/DC)等集成到电源管理单元(PMU)中。这样可实现更高的电源转换效率和更低功耗，及更少的组件数以适应缩小的板级空间，成本更低。 +   在大部分情况下，PMU等同于PMIC，但是这里讨论的SOC外部的供电芯片是PMIC, SOC内部的电源管理单元被称为PMU。 + +**3.DC_DC** +   DC_DC指直流转直流电路，广义上包括所有输入输出都是直流的电源，下文将要提到的LDO，也是一种DC_DC。这里我们所说的DC_DC实际上指的是DC_DC最典型的一种实现形式：开关恒流源。蜂窝基带的DC_DC一般都是BUCK电路，根据用途的不同会附带一些特殊功能，例如： + +**DVC_BUCK_DC/DC电路：**给CPU供电：负载能力强，带DVC（动态调节电压）功能，允许动态调整电压，达到节能目的。 +**APT_BUCK_DC/DC电路：**给射频以及PA供电：负载能力强，带APT（平均功率追踪）功能，减少射频耗电。 + +   从用途上可以很明显看出来，DC_DC的优势是负载大。除了负载，它还有输入范围宽、转换效率高的优点。相对于LDO，它的缺点是结构复杂，负载响应差，纹波较大，不适合给对噪声敏感的电路供电。 + +**4.LDO** LDO是一种线性电源，只能做降压，负载能力较弱。但它结构简单，成本低，适合大规模铺设。而且噪声小，负载响应快，在对噪声敏感的模拟电路内用LDO是最好的选择。 蜂窝基带内一般用来给各个分立器件或外设供电（如RTC电路、GPIO、UART等），这些器件对负载的要求不高。利用LDO可以方便的实现多电压域的低噪声电路。 - -### 1.5 动态调整电压（DVFS/DVC） -DVFS 即动态电压频率调整，动态技术则是根据芯片所运行的应用程序对计算能力的不同需要，动态调节芯片的运行频率和电压(对于同一芯片，频率越高，需要的电压也越高)，从而达到节能的目的。 -DVFS本质上是一种低功耗技术，目的是根据芯片当时的实际功耗需要设定工作电压和时钟频率，这样可以保证提供的功率既满足要求又不会性能过剩，从而可以降低功耗。 -我们的通信模组中给CPU供电的BUCK电路一般都带有电压调整功能，根据芯片实际的时钟频率来调整输出电压。 - -### 1.6 RTC电路 +**5.RTC** +RTC(Real time clock)的含义是实时时钟，它为人们提供精确的实时时间，或者为电子系统提供精确的时间基准。实时时钟芯片大多采用精度较高的晶体振荡器作为时钟源（对蜂窝模组来说，RTC适配的晶振一般都是32768 Hz，这个频率能达到的计时精度相对最高）。有些RTC在CPU关机时，PMIC仍保持RTC电路的供电，故可以继续保持运行。 + +以上，我们介绍了电源管理中经常出现的功能和技术，现代PMIC经常用这些技术，完成电源管理的既定目标。其硬件连接、具体功能和实现方法将在下个章节进行描述。 + +## 4.PMU 硬件框架 + +PMU的内部典型硬件框图如下 -通信模组使用的PMIC通常集成RTC电路（一般包括一路常开的LDO和硬件定时器），以内置/外置晶振作为时钟源计数，可以在模组的CPU下电时保持计数，并在PMIC上产生唤醒源，从而实现定时开机功能。 - -### 1.7 模拟电路 -PMIC一般集成ADC和温度传感器，部分型号（ECX00U）集成了音频codec，模组所需的模拟电路功能实际上大部分由PMIC实现。 - -### 1.8 充电管理电路 -一般当USB_VBUS连接且电压在合法范围内时启动，其功能包括两点：1.从VBUS上取电，经转换后经VBAT向电池充电 2.预留了部分充电组件接口，如：充电指示灯、电池的温度传感器，电池ID检测等。 +![PMIC_example](../media/system/power-manager/PMIC_example.png) -### 1.9 其它外设 -**powerkey：**模组的powerkey在PMIC的定义上一般叫做exton，其作用就是触发PMIC给CPU供电。开机状态下也可以控制模组关机。 +在典型的SOC供电系统中，PMIC/PMU的硬件连接一般如下图： -**晶振：**给模组内提供震荡源，一般是休眠时模组32K低速时钟的源。 +![PMIC_HD](../media/system/power-manager/PMIC_CPU_Hardware.png) -**GPIO:** 部分资源比较丰富的PMIC上还集成了GPIO，与连接在CPU的GPIO相比，这些GPIO在关机时仍可保持电平。 +可见，在电源的输入输出之外，PMU最主要的对外连接引脚有以下几个： +**1.power_en：**一般即是通信模组的powerkey，在这个引脚中断被触发时，PMIC会主动改变SOC的电源状态，给CPU供电，触发整个SOC的开机行为。在开机状态下，这个引脚中断仍然可用，可以在应用层绑定对应行为。 +**2.PMBus：**PMBus 是一种低成本的双线接口，是 SMBus 标准的扩展，该标准基于 I2C 协议构建。由于 PMBus 是 SMBus 协议的扩展，因此它共享其大部分物理层以及总线的运行方式。但是，PMBus 定义了电源控制和管理组件所需的一组特定命令和数据结构。 +   PMBus基于I2C协议，只需要两个必选引脚（SDA和SCL），因此具有成本低，扩展性强等优点。在蜂窝模组中，常选用PMBus来作为PMIC和其它器件的通信协议（也有部分，如EC21，使用SPMI协议）。从而使PMIC能控制、监测整个模组的电源状态。同时，CPU也可以通过PMBus来改写PMU的寄存器，从而实现应用层对电源状态的控制。 +   除此之外，蜂窝模块的部分传感器电路（一般是ADC、温度传感器）就铺设在PMU上，CPU需要这些传感器的数据时，也会通过PMBus访问PMU对应的寄存器。 +**3.PSM_INT：**只在PSM休眠下生效的接口，可用来唤醒PSM休眠。一般支持PSM休眠模式的蜂窝模块都会引出。 -### 1.10 输入电路 +藉由以上所述的硬件构型，PMU在蜂窝模组中能实现诸如电源管理、唤醒PSM休眠、电压检测和温度检测功能。以下章节我们将具体介绍PMU的具体功能、实现细节和使用方法。 -PMIC一般由一路或几路电压相对较高的直流做输入，经过VIN电路稳压后供给PMIC各个部分。VIN一般连接在模组的VBAT上。需要注意的是，部分PMIC功能较简单的模组（如ECX00M和ECX00E），无法通过PMIC给射频供电，需要额外增加射频供电单元（但一般保留了控制射频电源通断的功能）。 +## 5.PMU主要功能介绍 -## 2. Powerkey和Reset +### 5.1. Powerkey和Reset -### 2.1 Powerkey的硬件连接和开关机原理 +#### 5.1.1 Powerkey的硬件连接和开关机原理 Powerkey，可以控制模组开关机。其硬件连接PMIC，模组通电时，PMIC处于在电状态，但并不给CPU供电。此时若powerkey被按下，则开始向CPU供电，CPU从bootrom开始运行。但经过bootloader阶段的消抖，实际上PWRKEY必须长按才能让模组真正开机。 -**开关机时序图:** +**开机时序图:** ![PowerkeyOn](../media/system/power-manager/PowerkeyOn.png) -![PowerkeyOff](../media/system/power-manager/PowerkeyOff.png) +**关机时序图:** -### 2.2 Powerkey长按开机的实现 +![PowerkeyOff](../media/system/power-manager/PowerkeyOff.png) +#### 5.1.2 Powerkey长按开机的实现 在bootloader中对Powerkey进行电平检测和消抖，由于bootloader中一般不能使用ISR，实际的消抖大部分是轮询powerkey状态，保持低电平的时间低于消抖阈值则操作PMIC关机。 -### 2.3 RESET的硬件连接和重启原理 - RESET一般是直接连接在CPU上的，其触发的动作并不涉及PMIC，只是CPU复位，中断向量表回到bootrom，然后从bootrom开始执行。 - RESET时序图： +#### 5.1.3 RESET的硬件连接和重启原理 +RESET一般是直接连接在CPU上的，其触发的动作并不涉及PMIC，只是CPU复位，中断向量表回到bootrom，然后从bootrom开始执行。 +**RESET时序图：** ![PowerkeyOff](../media/system/power-manager/Reset.png) -### 2.4 自定义Powerkey短按长按功能 +#### 5.1.4 自定义Powerkey短按长按功能 一般是在能够双边触发的powerkey上实现。实现方法是在按下时的中断里启动一个定时器，在抬起的中断里关闭这个定时器。如果定时器尚未到期，就被pwrkey抬起的中断关闭，则判定为短按。如果直到超时都没有抬起的中断触发，则判定为长按。定时器的时间就是界定短按和长按的阈值。 -### 2.5 上电自启动功能实现 +配置powerkey自定义功能用法：[class PowerKey - power key按键回调注册功能 ](https://python.quectel.com/doc/API_reference/zh/peripherals/misc.PowerKey.html) -如需上电自动开机功能且不考虑关机（ECX00M在这种场景下无法关机），则可以把 PWRKEY 直接下拉到地，下拉电阻建议不超过 1 kΩ。 +配置powerkey自定义短按/长按示例代码： -![autostart](../media/system/power-manager/autostart.png) +```python +from misc import PowerKey +import osTimer -## 3. USB_BOOT +class Pwrkey(object): + def __init__(self, time_threshold): + self.pk = PowerKey() + self.time_threshold = time_threshold + self.timer = osTimer() + self.is_long_press = 0 + self.pk.powerKeyEventRegister(self.pwk_callback) + + def long_press_cb(self): + print('powerkey long press.') + + def short_press_cb(self): + print('powerkey short press.') -### 3.1 USB_BOOT概述 - 模组固定的一个IO引脚，bootrom阶段检测到此引脚处于某种特定的电平时，直接跳转到强制下载/紧急下载模式。开机后可当作普通IO使用。 + def pwk_timer_cb(self, arg): + self.is_long_press = 1 + + def pwk_callback(self, status): + if status == 0: + print('powerkey release.') + self.timer.stop() + if self.is_long_press: + self.long_press_cb(); + else: + self.short_press_cb(); + + elif status == 1: + print('powerkey press.') + self.is_long_press = 0 + self.timer.start(self.time_threshold, 0, self.pwk_timer_cb) -### 3.2 强制下载的实现原理 - 模组固件被破坏或未烧录时，USB_BOOT仍能够被正常触发。USB_BOOT的引脚号、触发电平和下载模式跳转全部固化在硬件的ROM中，且此ROM的代码入口就是CPU的复位向量，即使可擦写存储介质中的代码损坏，也不影响此处USB_BOOT的行为。 -### 3.3 使用方法 -使用场景：首次烧录、救砖、不方便使用软件控制进入下载模式的场景 -使用方法：将usb_boot短接到地（部分模组，如EC600U/EC600E是上拉到1.8V，具体触发电平可在硬件规格书中获取），然后上电。此时USB不再和正常启动时一样枚举多个口，上位机只能看到一个下载口 +if __name__ == "__main__": + pwrkey = Pwrkey(1000) -> 可能的下载口名称： -> Quectel Download Port(ECX00N, ECX00M) -> Quectel QDLoader 9008(BG95/BG77) -> Quectel QDLoader Port(ECX00E) -> SPRD U2S Port(ECX00U ECX00G) -此时在上位机启动烧录软件，烧录软件操作如下： -**QPYCom:**载入固件后，根据型号选中模组对应下载口，然后点击“固件下载”进行烧录 -**QFLASH**：载入固件后，根据型号选中模组对应下载口，然后点击“Start”进行烧录 -**原厂工具**（仅了解，客户侧禁止使用）：载入固件后，点击开始烧录，原厂工具都会自动检测下载口，然后进行下载协议握手和烧录 - -**USB_BOOT开机时序图：** +``` -![USB_BOOTTime](../media/system/power-manager/USB_BOOTTime.png) -> 注意事项：不期望进行下载时，注意在开机流程结束前保护此引脚电平，防止模组检测到此引脚被触发从而进入下载模式 -## 4. 设备启动流程 +#### 5.1.5 上电自启动功能实现 -### 4.1启动流程概述 -总体来说，启动流程可分为以下四个部分： -1.bootrom，上电立即运行的部分，一般固化在硬件的ROM内 -2.bootloader，初始化必要外设并检查内置存储中的代码，满足启动条件后跳转到RTOS启动部分 -3.RTOS，此处会完成RTOS的初始化，并且启动系统必要的task，此流程的最后会创建QuecPython虚拟机线程 -4.QuecPython虚拟机启动，完成交互口、虚拟文件系统、网络环境的初始化后，在usr分区中寻找main.py并执行 -总流程图如下： +如需上电自动开机功能且不考虑关机（ECX00M在这种场景下无法关机），则可以把 PWRKEY 直接下拉到地，下拉电阻建议不超过 1 kΩ。 -![Mainstartup](../media/system/power-manager/Mainstartup.png) +**上电自启动典型设计电路：** -### 4.2.bootrom -bootrom是固化在模组硬件中的代码，复位向量代码即指向此处。当模组上电或复位时会立即执行此处的逻辑，一般包含强制下载检测、基本初始化等功能。运行结束前会检测并引导bootloader。 +![autostart](../media/system/power-manager/autostart.png) -![bootrom](../media/system/power-manager/bootrom.png) -### 4.3.bootloader +### 5.2 PSM_INT +#### 5.2.1 PSM_INT概述 +PSM_INT是PMIC上的一个引脚，它的特征是在PSM模式下仍能响应，并触发模组唤醒。但需要注意的是，在关机模式下，这个引脚一般是失效的。也就是说，PSM_INT是一个仅在PSM模式下生效的唤醒源。 -bootloader一般存储在内置存储中，作为第二级 boot，完成一些不确定的，相对复杂的，不方便在bootrom阶段完成的功能。 -不同平台的bootloader功能不尽相同，以下介绍其典型流程。 +#### 5.2.2 PSM_INT的原理 +ECX00U&BG95/BG77：PMIC上的引脚，进入PSM模式时，PMIC默认使能其中断，触发时会将模组从PSM中唤醒。 +ECX00E：与之类似的是六个wakeup引脚，需要在模组进入PSM前使能这几个wakeup引脚，并打开对应的中断控制器，触发时会将模组从PSM中唤醒。 -![bootloader](../media/system/power-manager/bootloader.png) +#### 5.2.3 使用方法 +ECX00U&BG95/BG77：进入PSM时默认开启使能，具有固定的电平状态和触发条件，进入PSM模式时直接触发即可。 +ECX00E：需要配置使能哪几路wakeup，可设定自身电平状态和触发条件。 -#### 4.3.1 基本BSP外设初始化 +### 5.3 休眠GPIO电平控制 -bootloader中需要操作一些外设，如GPIO、UART等，此时会把这些外设进行初始化 +#### 5.3.1 GPIO硬件概述 +在大部分情况下，蜂窝模组的GPIO从CPU引出，但供电则来自PMIC的一路或多路LDO。此类GPIO能正常工作的前提条件有两个： +1.CPU使能GPIO（一般是写GPIO对应的寄存器，如果作输入，还要保证GPIO中断被打开）。 +2.PMU保持GPIO的供电。 +上述二者有任何一点不满足，都会导致GPIO失控。因此，我们需要特别关注休眠情况下GPIO电平的变化。 -#### 4.3.2 powerkey消抖 +但需要注意的是，部分资源较为充裕的PMIC会直接引出GPIO。这类GPIO并不需要CPU的控制，而是由PMIC直接提供电源并控制其状态。这种GPIO是否保持正常功能完全取决于PMIC，只要PMIC能保持电源，就可以维持GPIO的状态，关于这两种GPIO在休眠时的行为，我们会在下一段仔细介绍。 -bootloader中一般不能使用ISR，powerkey消抖即是在阈值时间内轮询powerkey的电平，如果其电平保持时间超过阈值时间，则继续进行开机流程。反之，则对此次powerkey触发进行消抖，操作PMIC关机。 +#### 5.3.2 休眠时GPIO电平变化 +**sleep：**对绝大部分蜂窝模组而言，sleep1下CPU的GPIO控制器并不会掉电，此时所有GPIO保持电平状态不变，中断可以触发。 -#### 4.3.3 判断是否进行FOTA +> 特例是ECX00E，此平台在sleep下会停止GPIO的供电并关闭对应中断。AONGPIO可保持输出电平，其余GPIO全部下电，GPIO中断不可触发。 -大部分模组的FOTA依赖bootloader内进行跳转。一般上一次关机前会操作某个寄存器作为flag，标识需要进行fota。检测到FOTA的flag时，bootloader便不会跳转到RTOS系统，而是跳转到updater（一般是一块可以独立运行的代码，会将fota包内容写到指定的flash地址，完成固件的升级）。 +**PSM&关机：**CPU掉电，和CPU连接的GPIO随之掉电，变成低电平。但PMIC上的GPIO仍在电，可以维持电平不变。 -#### 4.3.4 相关外设去初始化，跳转RTOS系统启动 +> 对我们的蜂窝模组而言，PMIC有GPIO输出的仅EC21。 -将bootloader中使用过的外设去初始化，恢复到操作前的状态。校验RTOS代码区域的完整性，校验通过则跳转到RTOS入口函数，不通过一般会认为镜像损坏，跳进下载模式。 +#### 5.3.3 休眠GPIO电平控制原理 +休眠时，模组并不会去操作GPIO状态相关的寄存器，PMU也不会切断GPIO的供电，所以GPIO的电平一般保持不变。 +反之，关机或PSM时CPU下电，GPIO控制器也随之下电，GPIO无法保持电平。但此时PMIC仍在电，所以引出自PMIC的GPIO不受影响。 -（ECX00N/M跳转到LOGO阶段，读取文件系统中的图片资源，并初始化LCD驱动，完成开机LOGO的显示，LOGO结束后跳转到RTOS） +> ECX00E为了降低休眠功耗，关闭了GPIO的供电LDO，所以这个型号的GPIO在休眠时会全部掉电。 -### 4.4 RTOS启动 -RTOS是模组运行的主体程序，绝大部分通信模组此时会初始化两套RTOS，分别处理CP和AP任务。一般启动流程如下： +### 5.4 VDD_EXT +#### 5.4.1 VDD_EXT概述 +一路直接连接到LDO或者常开IO的引脚，CPU上电时LDO开始供电，此引脚立刻拉高，并在开机时一直保持高电平。可用来标识CPU上电时间，可以作为常开的电源或上拉，部分连接在常开LDO上的VDD_EXT在BB芯片下电后仍能保持高电平。 -![RTOS](../media/system/power-manager/RTOS.png) +#### 5.4.2 VDD_EXT电平-时序图 -#### 4.4.1 时钟和外设进行初始化，为RTOS启动做好准备 -为了获得准确的sys_tick，CPU的tick会被重新初始化（即tick恢复到0）。所有外设也会被置为上电初始状态。此时的BSP状态应和模组默认电平相对齐。 +![VDD_EXTTime](../media/system/power-manager/VDD_EXTTime.png) -#### 4.4.2 RTOS初始化 +#### 5.4.3 典型应用 +**标识模组电源状态：**前面的章节我们描述过，powerkey被触发时，PMIC会给CPU上电并改变整个模组的电源状态，VDD_EXT会在此时同步被拉高。因此，VDD_EXT的电平状态可以作为整个模组电源状态的标志。 -初始化任务堆栈、任务调度器，当任务调度器初始化完成，rtos就已经接管了底层，我们调用的函数开始全部运行在RTOS的任务中。 +**作为模组开机时常开的电源或上拉：**由于VDD_EXT在开机时会一直保持高电平，且具有一定的输出能力，因此可以作为常开的上拉或者电源使用。 -#### 4.4.3 CP core启动搜网和SIM卡相关任务 +> 由于VDD_EXT一般由LDO供电，驱动能力并不高，作电源使用时，请务必确认是否满足用电器的耗流需求。 -CP侧开始启动搜网和SIM卡相关任务，原厂的CP core一般不开源，此处不再赘述 +### 5.5 RTC闹钟 +#### 5.5.1 RTC 闹钟概述 +RTC（Real Time Clock）是PMIC上的一个单元，一般由一路关机时也可保持供电的LDO来驱动，其核心部件是数目不等的计数器，通过32K时钟源进行计数，并将实时时间存储在寄存器中，CPU可访问这个寄存器来获取时间。RTC alarm到期时可以产生中断，大部分型号可唤醒模组。 -#### 4.4.4 AP core启动必要的内部task +#### 5.5.2 RTC 闹钟原理 +如之前章节所述，RTC(Real time clock)的含义是实时时钟，一般PMIC都有搭载。RTC alarm是在实时时钟的基础上增加了一组或多组alarm寄存器，可存储目标时间。当RTC的实时时钟超过目标时间时（一般称之为expired），会触发alarm中断，此中断可在应用层绑定相应任务，亦可作为唤醒源触发整个模组的唤醒/开机动作。 -WDT、FS、协议栈等必要的内部task启动，完善APP运行的条件。 +大部分模组（ECX00N和ECX00E不支持此功能）都可在关机时保持RTC工作，并且被RTC_alarm的中断唤醒。 -#### 4.4.5 启动QuecPython虚拟机 +> 注意事项： +> ECX00E没有RTC电路，其所谓RTC闹钟是硬件定时器实现的，可以在任何休眠等级下产生有效唤醒，但关机时不可用。 +> BG95/BG77的RTC alarm和PSM T3412复用一个alarm寄存器，因此不能共存。 +> 定时精度，BG95/BG77平台定时精度需要专门校准调整 +> 唤醒频率，ECX00E在特定sleep时会将RTC_alarm寄存器写入flash，会涉及到擦写flash的操作，不宜太频繁 -RTOS内部环境初始化完成，启动APP task。APP一般是一个优先级相对较低的task，用来处理第三方业务。相对于底层而言，我们的python虚拟机就是一个APP，在RTOS初始化完成后启动。 +#### 5.5.3 典型应用 -## 5. 开机APP自动运行 +应用方法参考：[class RTC – 实时时钟 ](https://python.quectel.com/doc/API_reference/zh/peripherals/machine.RTC.html) -QuecPython虚拟机是python运行的基础，虚拟机在启动时会完成交互命令行、文件系统和网络环境的初始化，并在最后默认执行名为main.py的pyscript +**1.开机情况下的使用** +开机时可作为定时器使用，实现定时任务。 -大致流程如下： +**2.关机情况下唤醒** +设置alarm时间后将模组关机（但不可完全断电）。关机时若RTC闹钟超时，会触发开机。可利用此特性实现低功耗，在不需要处理业务时将设备关机，需要处理业务时再唤醒设备。 -![pythonVM](../media/system/power-manager/pythonVM.png) -### 5.1 虚拟机本身的初始化 -包括栈、GC、python解释器等虚拟机组件初始化，初始化完成后已经能运行pyscript，此时进入\_boot.py进行下一步初始化. +### 5.6 ADC +#### 5.6.1 ADC概述 +模拟数字转换器即A/D转换器，或简称ADC，通常是指一个将模拟信号转变为数字信号的电子元件。通常的模数转换器是将一个输入电压信号转换为一个输出的数字信号。 -### 5.2 虚拟文件系统初始化 -要在python中访问文件系统，就要把模组上实体的文件系统挂载到python的VFS上。部分模组底层没有初始化我们需要的liitleFS文件系统，此时就要将实体文件系统一并初始化。 +#### 5.6.2 ADC原理 +这种转换器的基本原理是把输入的模拟信号按规定的时间间隔采样，并与一系列标准的数字信号相比较，数字信号逐次收敛，直至两种信号相等为止，然后显示出代表此信号的二进制数。 -当实体文件系统没有初始化成功、SPI通信失败等情况导致此步骤执行失败，模组会继续开机流程。但会直接跳过app_fota和备份还原，这两个功能和文件系统是强依赖，文件系统未能初始化成功时执行必定失败，没有意义。 +蜂窝模组的PMIC一般有多路ADC，一般有一路固定对VBAT进行采样，监测VBAT的电压是否在合法范围内。还有数路开放对外，用户可自行连接需要采样的设备，并在应用层读取这些ADC的值。 -### 5.3 备份还原 -启用备份还原机制时，若usr中文件出现丢失或者更改，会从bak分区将备份文件恢复进usr。若未开启备份还原机制，或者usr内文件没有变更时，则直接跳过备份还原流程。 +#### 5.6.3 典型应用 -### 5.4 app_fota +**1.检测模组VBAT电压** +**使用方法：**[power - 获取电池电压](https://python.quectel.com/doc/API_reference/zh/peripherals/misc.Power.html#%E8%8E%B7%E5%8F%96%E7%94%B5%E6%B1%A0%E7%94%B5%E5%8E%8B) +这一路ADC固定连接在模组的VBAT上，我们可以在应用层监控模组VBAT的电压，在使用电池给模组供电时，此接口可以实现对电池的管理。 +除了获取电压之外，当此路ADC探测到VBAT电压过高或过低时，会在PMIC上触发超压/低压的中断。此时为了保护模组硬件，PMIC会主动改变电源状态，指令整个模组下电关机。 -检测是否进行APP_FOTA。APP_FOTA在下载完成后会在文件系统中写入fota标志，如果在文件系统中读到这个标志，就会进行app_fota升级流程。将下载的内容更新到usr分区。 +**2.ADC的使用** +**使用方法：**[class ADC - 模数转换](https://python.quectel.com/doc/API_reference/zh/peripherals/misc.ADC.html) +将输出模拟量的设备连接到ADC上，可以读取到设备输出的电压幅值。此时我们在业务中利用这个设备的电压幅值来计算传感数据。 -### 5.5 交互命令行初始化 -从此环节开始，是一定会执行到的流程，repl命令行启动，如果system_config.json中开启了交互保护，则会打开交互保护功能。 +> 不同的PMIC，搭载ADC的有效检测范围也是不同的，需要根据硬件手册来确定。如果模拟设备的输出范围和ADC的检测范围不符，就需要在硬件上设计分压，将输出电压和ADC的有效范围做匹配。业务里再通过检测到的电压来反推模拟设备的真实输出值。 -### 5.6 自动拨号 -网络环境初始化，根据system_config.json中的配置决定是否进行开机自动拨号(默认开启)。 +### 5.7 高温保护 +#### 5.7.1 高温保护概述 +PMIC的模拟电路中，往往附带了温度传感器。由于温度过高时，集成电路存在诸如性能下降、频率响应变差、背景噪声增加，乃至电路熔毁的风险；PMIC在侦测到过高的温度时，会主动改变电源状态，指令整个模组下电关机。 -### 5.7 pyscript运行 -以上步骤均结束后，检测usr文件系统内是否有名为main.py的脚本，有则立即运行此脚本。因此，main.py是APP任务的固定入口点。 +#### 5.7.2 高温保护原理 +温度传感器是一个模拟器件，其输出电压随着温度变化而变化，PMIC通过ADC采集其输出电压，计算模组温度。PMIC会轮询温度传感器的值，当这个值超过模组的安全工作温度时，立即改变电压状态，指令模组下电关机，保护硬件。 -## 6. 开机LOGO显示 +#### 5.7.3 典型应用 -### 6.1 开机LOGO的使用场景 -开机LOGO一般需求尽量快的显示，由于虚拟机初始化和APP载入需要一定时间，因此要在此虚拟机启动前先显示LOGO +高温保护一般是PMIC的内置逻辑，从探测到实际的保护动作都由PMIC完成，安全工作温度的范围一般也是由厂家设定，应用层一般无需关注。 -### 6.2 方案1：bootloader（ECX00M/N方案） -在bootloader中引入LCD和文件系统部分的代码，在bootloader阶段完成LCD显示，适用于boot时间较长的场景。 +### 5.8 其它功能 -ASR模组bootloader的最后会进入名为LOGO的代码块，这里我们适配了littleFS文件系统和SPI LCD驱动，可以直接访问usr分区的数据，并驱动LCD显示LOGO。由于usr分区在上层可以直接修改，客户可以方便的更换LOGO图像。 +**看门狗：**看门狗，又叫watchdog timer，是一个定时器电路，一般有一个输入，叫喂狗(kicking the dog/service the dog），一个输出可以控制CPU复位。CPU正常工作的时候，每隔一段时间输出一个信号到喂狗端，给 WDT清零，如果超过规定的时间不喂狗（一般在程序跑飞时），WDT定时超过，就会给出一个复位信号到CPU，使CPU复位，防止其死机。看门狗的作用就是防止程序发生死循环，或者说程序跑飞。 -### 6.3 方案2：RTOS（ECX00U展锐方案） -在RTOS初始化完成，但APP尚未启动时，先刷新屏幕，显示LOGO，然后再进行python虚拟机的初始化，适用于boot较快的场景。 +**Codec：**在硬件层面，音频编解码器指一个能编码模拟音频到数字音频和解码数字音频到模拟音频的独立设备。换种说法，它包含运行在同样时钟的模数转换器（ADC）和数模转换器（DAC）。部分PMU将音频Codec集成在模拟电路部分，让模组电路能够更精简。 -在python还没启动时提前将lfs文件系统挂载到ECX00U底层的vfs上，就可以在虚拟机初始化之前访问文件系统并驱动LCD显示LOGO，同样的，LOGO图片报此马在usr分区，客户可以直接在python层进行修改。 +**设备充电：**充电管理单元是PMIC中相对独立的单元，包括充电电路、电池传感器、充电状态指示灯驱动电路等。 -### 6.4 自定义显示 -以上两种方案，其显示内容都存储在我们的文件系统usr分区内，用户在python层修改usr分区内的logo内容即可。 +充电管理是相对独立的功能，有自己的硬件单元和控制逻辑，接下来我们着重介绍。 -## 7. 设备充电 +## 6. 设备充电 -### 7.1 充电方案概述 +### 6.1 充电方案概述 通信模组的充电方案一般是借由PMIC的充电管理单元来实现的，部分模组（ECX00U）可以在模组开机的情况下，在软件中介入充电控制。 -#### 7.1.1 PMIC 充电管理单元原理 +#### 6.1.1 PMIC 充电管理单元原理 PMIC充电管理单元的实现形式一般是一个linear charger（线性充电器），只要检测到VBUS电压在合法范围，就会开始工作。 +**典型充电管理单元的架构和硬件连接：** +![](../media/system/power-manager/Charger_example.png) + 充电单元的传感器一般至少包括两个ADC，一路监控VBAT电压，另一路监控电池内阻（实际上通过内阻的变化来监控电池温度）。 -#### 7.1.2 充电阶段控制 +#### 6.1.2 充电阶段控制 根据VBUS电压高低，PMIC会控制充电管理单元进入不同的充电管理阶段，典型划分如下(不同平台称谓不同，原理大致相似)： 涓流模式/激活模式：电池电压低于某个阈值时，电池管理系统会禁止向电池中充电，此时需要用小电流激活电池，使电池电压恢复到可充电状态。 @@ -260,18 +336,18 @@ PMIC充电管理单元的实现形式一般是一个linear charger（线性充 复充：充电完成后，轮询VBAT电压，发现VBAT滑落到复充触发电压以下时，则进行恒压充电。 -典型的充电电流、电压曲线图如下： +**典型的充电电流、电压曲线图如下：** ![ChargerCurrent](../media/system/power-manager/ChargerCurrent.png) -#### 7.1.3 充电的软件控制 +#### 6.1.3 充电的软件控制 允许通过软件调节充电行为，如停止/启动充电，控制恒流模式时的输出占空比，或者获取电池电压和温度等（仅ECX00U支持）。 -### 7.2 关机充电方案 -#### 7.2.1 关机充电方案概述 +### 6.2 关机充电方案 +#### 6.2.1 关机充电方案概述 关机充电，即在关机状态下插入电源进行充电时，在不开机的情况下，实现对充电状态的监控。 -#### 7.2.2 实现方案原理 +#### 6.2.2 实现方案原理 充电单元本身含有控制充电阶段的FSM，可以在CPU不运行的情况下控制充电行为，所以我们要实现的即是在不开机的情况下，监控充电状态（如VBAT电压、电池温度等，可能还需要进行显示）。 此时，可在VBUS被电源拉高时通过硬件联动powerkey（如果PMIC支持charger插入触发开机，则无需触发powerkey，使能charger触发开机即可），CPU上电。 @@ -280,67 +356,151 @@ PMIC充电管理单元的实现形式一般是一个linear charger（线性充 ![PoweroffCharger](../media/system/power-manager/PoweroffCharger.png) -### 7.3 平台支持情况 +### 6.3 平台支持情况 当前EC100Y和ECX00U内置充电管理，其它平台可外置充电管理芯片。 -## 8. PSM_INT -### 8.1 PSM_INT概述 -PSM_INT是PMIC上的一个引脚，它的特征是在PSM模式下仍能响应，并触发模组唤醒。但需要注意的是，在关机模式下，这个引脚一般是失效的。也就是说，PSM_INT是一个仅在PSM模式下生效的唤醒源。 -### 8.2 PSM_INT的原理 -ECX00U&BG95/BG77：PMIC上的引脚，进入PSM模式时，PMIC默认使能其中断，触发时会将模组从PSM中唤醒。 -ECX00E：与之类似的是六个wakeup引脚，需要在模组进入PSM前使能这几个wakeup引脚和中断，触发时会将模组从PSM中唤醒。 -### 8.3 使用方法 -ECX00U&BG95/BG77：进入PSM时默认开启使能，具有固定的电平状态和触发条件，进入PSM模式时直接触发即可。 -ECX00E：需要配置使能哪几路wakeup，可设定自身电平状态和触发条件。 -## 9. 休眠GPIO电平控制 -### 9.1 GPIO电源供应概述 -GPIO从BB芯片引出。状态由BB芯片控制，供电多来自PMIC的LDO。GPIO的电平状态和PMIC行为息息相关，休眠时其电平变化取决于PMU行为。 +## 7. 设备启动流程 -### 9.2 休眠时GPIO电平变化 -sleep1：保持电平状态不变，中断可以触发。（ECX00E AGPIO可保持输出电平，其余GPIO由于LDO被拉低，全部下电，GPIO中断不可触发） -PSM&关机：GPIO全部变成低电平（EC21部分GPIO可保持电平，因为这些GPIO是连接在PMU上的，PMU仍然在电） +### 7.1启动流程概述 +总体来说，启动流程可分为以下四个部分： +1.bootrom，上电立即运行的部分，一般固化在硬件的ROM内 +2.bootloader，初始化必要外设并检查内置存储中的代码，满足启动条件后跳转到RTOS启动部分 +3.RTOS，此处会完成RTOS的初始化，并且启动系统必要的task，此流程的最后会创建QuecPython虚拟机线程 +4.QuecPython虚拟机启动，完成交互口、虚拟文件系统、网络环境的初始化后，在usr分区中寻找main.py并执行 +总流程图如下： -### 9.3 休眠GPIO电平控制原理 -休眠时，模组并不会去操作GPIO状态相关的寄存器，PMU也不会切断GPIO的供电，所以GPIO的电平一般保持不变。 -反之，关机或PSM时BB芯片失电，与之相连的GPIO自然不能保持电平，但PMIC仍在电，若有GPIO自PMIC引出，则有可能保持电平。 +![Mainstartup](../media/system/power-manager/Mainstartup.png) -同样的，ECX00E为了降低休眠功耗，关闭了GPIO的供电，所以这个型号的GPIO在休眠时会全部掉电。 +### 7.2.bootrom +bootrom是固化在模组硬件中的代码，复位向量代码即指向此处。当模组上电或复位时会立即执行此处的逻辑，一般包含强制下载检测、基本初始化等功能。运行结束前会检测并引导bootloader。 -## 10. VDD_EXT -### 10.1 VDD_EXT概述 -一路直接连接到LDO或者常开IO的引脚，BB芯片上电时LDO开始供电，此引脚立刻拉高，并在开机时一直保持高电平。可用来标识CPU上电时间，可以作为常开的电源或上拉，部分连接在常开LDO上的VDD_EXT在BB芯片下电后仍能保持高电平。 +### 7.3.bootloader -### 10.2 VDD_EXT电平-时序图 +bootloader一般存储在内置存储中，作为第二级 boot，完成一些不确定的，相对复杂的，不方便在bootrom阶段完成的功能。 +不同平台的bootloader功能不尽相同，以下介绍其典型流程。 -![VDD_EXTTime](../media/system/power-manager/VDD_EXTTime.png) +#### 7.3.1 基本BSP外设初始化 +bootloader中需要操作一些外设，如GPIO、UART等，此时会把这些外设进行初始化 -### 10.3 典型应用 -标识BB芯片上电时间 -作为模组开机时常开的电源或上拉（做电源时，注意驱动能力是否满足需求）。 +#### 7.3.2 powerkey消抖 -## 11. RTC闹钟 -### 11.1 RTC 闹钟概述 -RTC（Real Time Clock）是PMIC上的一个单元，一般由一路关机时也可保持供电的LDO来驱动，其核心部件是数目不等的计数器，通过32K时钟源进行计数。RTC alarm到期时可以产生中断，大部分型号可唤醒模组。 +bootloader中一般不能使用ISR，powerkey消抖即是在阈值时间内轮询powerkey的电平，如果其电平保持时间超过阈值时间，则继续进行开机流程。反之，则对此次powerkey触发进行消抖，操作PMIC关机。 -### 11.2 RTC 闹钟原理 -RTC闹钟原理：提供专门的RTC_alarm寄存器，使能alarm时，向该寄存器中存储alarm触发的时间。当RTC时钟到达RTC_alarm寄存器中存储的时间（一般称此事件为Expire），即产生中断。 +#### 7.3.3 判断是否进行FOTA -大部分模组（ECX00N和ECX00E不支持此功能）都可在关机时保持RTC工作，并且被RTC_alarm的中断唤醒。 +大部分模组的FOTA依赖bootloader内进行跳转。一般上一次关机前会操作某个寄存器作为flag，标识需要进行fota。检测到FOTA的flag时，bootloader便不会跳转到RTOS系统，而是跳转到updater（一般是一块可以独立运行的代码，会将fota包内容写到指定的flash地址，完成固件的升级）。 -> 注意事项： -> 移芯没有RTC电路，其所谓RTC闹钟是硬件定时器实现的，可以在任何休眠等级下产生有效唤醒，但关机时不可用。 -> 高通MDM9x05的RTC alarm和PSM T3412复用一个alarm寄存器，因此不能共存。 -> 定时精度，BG95平台定时精度需要专门校准调整 -> 唤醒频率，移芯在特定sleep时会将RTC_alarm寄存器写入flash，会涉及到擦写flash的操作不宜太频繁 +#### 7.3.4 相关外设去初始化，跳转RTOS系统启动 -### 11.3 典型应用 +将bootloader中使用过的外设去初始化，恢复到操作前的状态。校验RTOS代码区域的完整性，校验通过则跳转到RTOS入口函数，不通过一般会认为镜像损坏，跳进下载模式。 -应用方法参考：[class RTC – 实时时钟 ](https://python.quectel.com/doc/API_reference/zh/peripherals/machine.RTC.html) +（ECX00N/M跳转到LOGO阶段，读取文件系统中的图片资源，并初始化LCD驱动，完成开机LOGO的显示，LOGO结束后跳转到RTOS） -#### 11.3.1 开机情况下的使用 -开机时可作为定时器使用，实现定时任务。 -#### 11.3.2 关机情况下唤醒 -设置alarm时间后将模组关机（但不可完全断电）。关机时若RTC闹钟超时，会触发开机。可利用此特性实现低功耗，在不需要处理业务时将设备关机，需要处理业务时再唤醒设备。 +### 7.4 RTOS启动 +RTOS是模组运行的主体程序，绝大部分通信模组此时会初始化两套RTOS，分别处理CP和AP任务。一般启动流程如下： + +![RTOS](../media/system/power-manager/RTOS.png) + +#### 7.4.1 时钟和外设进行初始化，为RTOS启动做好准备 +为了获得准确的sys_tick，CPU的tick会被重新初始化（即tick恢复到0）。所有外设也会被置为上电初始状态。此时的BSP状态应和模组默认电平相对齐。 + +#### 7.4.2 RTOS初始化 + +初始化任务堆栈、任务调度器，当任务调度器初始化完成，rtos就已经接管了底层，我们调用的函数开始全部运行在RTOS的任务中。 + +#### 7.4.3 CP core启动搜网和SIM卡相关任务 + +CP侧开始启动搜网和SIM卡相关任务，原厂的CP core一般不开源，此处不再赘述 + +#### 7.4.4 AP core启动必要的内部task + +WDT、FS、协议栈等必要的内部task启动，完善APP运行的条件。 + +#### 7.4.5 启动QuecPython虚拟机 + +RTOS内部环境初始化完成，启动APP task。APP一般是一个优先级相对较低的task，用来处理第三方业务。相对于底层而言，我们的python虚拟机就是一个APP，在RTOS初始化完成后启动。 + +## 8. 开机APP自动运行 + +QuecPython虚拟机是python运行的基础，虚拟机在启动时会完成交互命令行、文件系统和网络环境的初始化，并在最后默认执行名为main.py的pyscript + +大致流程如下： + +![pythonVM](../media/system/power-manager/pythonVM.png) + +### 8.1 虚拟机本身的初始化 +包括栈、GC、python解释器等虚拟机组件初始化，初始化完成后已经能运行pyscript，此时进入\_boot.py进行下一步初始化. + +### 8.2 虚拟文件系统初始化 +要在python中访问文件系统，就要把模组上实体的文件系统挂载到python的VFS上。部分模组底层没有初始化我们需要的liitleFS文件系统，此时就要将实体文件系统一并初始化。 + +当实体文件系统没有初始化成功、SPI通信失败等情况导致此步骤执行失败，模组会继续开机流程。但会直接跳过app_fota和备份还原，这两个功能对文件系统是强依赖，文件系统未能初始化成功时执行必定失败，没有意义。 + +### 8.3 备份还原 +启用备份还原机制时，若usr中文件出现丢失或者更改，会从bak分区将备份文件恢复进usr。若未开启备份还原机制，或者usr内文件没有变更时，则直接跳过备份还原流程。 + +### 8.4 app_fota +检测是否进行APP_FOTA。APP_FOTA在下载完成后会在文件系统中写入fota标志，如果在文件系统中读到这个标志，就会进行app_fota升级流程。将下载的内容更新到usr分区。 + +### 8.5 交互命令行初始化 +从此环节开始，是一定会执行到的流程，repl命令行启动，如果system_config.json中开启了交互保护，则会打开交互保护功能。 + +### 8.6 自动拨号 +网络环境初始化，根据system_config.json中的配置决定是否进行开机自动拨号(默认开启)。 + +### 8.7 pyscript运行 +以上步骤均结束后，检测usr文件系统内是否有名为main.py的脚本，有则立即运行此脚本。因此，main.py是APP任务的固定入口点。 + +## 9. 开机LOGO显示 + +### 9.1 开机LOGO的使用场景 +开机LOGO一般需求尽量快的显示，由于虚拟机初始化和APP载入需要一定时间，因此要在此虚拟机启动前先显示LOGO + +### 9.2 方案1：bootloader（ECX00M/N方案） +在bootloader中引入LCD和文件系统部分的代码，在bootloader阶段完成LCD显示，适用于boot时间较长的场景。 + +ASR模组bootloader的最后会进入名为LOGO的代码块，这里我们适配了littleFS文件系统和SPI LCD驱动，可以直接访问usr分区的数据，并驱动LCD显示LOGO。由于usr分区在上层可以直接修改，客户可以方便的更换LOGO图像。 + +*此处预备插入BSP同事提供的logo示例代码链接* + +### 9.3 方案2：RTOS（ECX00U展锐方案） +在RTOS初始化完成，但APP尚未启动时，先刷新屏幕，显示LOGO，然后再进行python虚拟机的初始化，适用于boot较快的场景。 + +在python还没启动时提前将lfs文件系统挂载到ECX00U底层的vfs上，就可以在虚拟机初始化之前访问文件系统并驱动LCD显示LOGO，同样的，LOGO图片报此马在usr分区，客户可以直接在python层进行修改。 + +*此处预备插入BSP同事提供的logo示例代码链接* + +### 9.4 自定义显示 +以上两种方案，其显示内容都存储在我们的文件系统usr分区内，用户在python层修改usr分区内的logo内容即可。 + +## 10. USB_BOOT + +### 10.1 USB_BOOT概述 + 模组固定的一个IO引脚，bootrom阶段检测到此引脚处于某种特定的电平时，直接跳转到强制下载/紧急下载模式。开机后可当作普通IO使用。 + +### 10.2 强制下载的实现原理 + 模组固件被破坏或未烧录时，USB_BOOT仍能够被正常触发。USB_BOOT的引脚号、触发电平和下载模式跳转全部固化在硬件的ROM中，且此ROM的代码入口就是CPU的复位向量，即使可擦写存储介质中的代码损坏，也不影响此处USB_BOOT的行为。 + +### 10.3 使用方法 +使用场景：首次烧录、救砖、不方便使用软件控制进入下载模式的场景 +使用方法：将usb_boot短接到地（部分模组，如EC600U/EC600E是上拉到1.8V，具体触发电平可在硬件规格书中获取），然后上电。此时USB不再和正常启动时一样枚举多个口，上位机只能看到一个下载口 + +> 可能的下载口名称： +> Quectel Download Port(ECX00N, ECX00M) +> Quectel QDLoader 9008(BG95/BG77) +> Quectel QDLoader Port(ECX00E) +> SPRD U2S Port(ECX00U ECX00G) + +此时在上位机启动烧录软件，烧录软件操作如下： +**QPYCom:**载入固件后，根据型号选中模组对应下载口，然后点击“固件下载”进行烧录 +**QFLASH**：载入固件后，根据型号选中模组对应下载口，然后点击“Start”进行烧录 +**原厂工具**（仅了解，客户侧禁止使用）：载入固件后，点击开始烧录，原厂工具都会自动检测下载口，然后进行下载协议握手和烧录 + +**USB_BOOT开机时序图：** + +![USB_BOOTTime](../media/system/power-manager/USB_BOOTTime.png) + +> 注意事项：不期望进行下载时，注意在开机流程结束前保护此引脚电平，防止模组检测到此引脚被触发从而进入下载模式