esp32 蓝牙启动流程_ESP32 启动流程

官网链接：https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/general-notes.html

应用程序的启动流程

本文将会介绍 ESP32 从上电到运行 app_main 函数中间所经历的步骤(即启动流程)。

宏观上，该启动流程可以分为如下 3 个步骤：

一级引导程序被固化在了 ESP32 内部的 ROM 中，它会从 Flash 的 0x1000 偏移地址处加载二级引导程序至 RAM(IRAM & DRAM) 中。

二级引导程序从 Flash 中加载分区表和主程序镜像至内存中，主程序中包含了 RAM 段和通过 Flash 高速缓存映射的只读段。

主程序运行，这时第二个 CPU 和 RTOS 的调度器可以开始运行。

下面会对上述过程进行更为详细的阐述。

一级引导程序

SoC 复位后，PRO CPU 会立即开始运行，执行复位向量代码，而 APP CPU 仍然保持复位状态。在启动过程中，PRO CPU 会执行所有的初始化操作。APP CPU 的复位状态会在应用程序启动代码的 call_start_cpu0 函数中失效。复位向量代码位于 ESP32 芯片掩膜 ROM 的 0x40000400 地址处，该地址不能被修改。

复位向量调用的启动代码会根据 GPIO_STRAP_REG 寄存器的值来确定 ESP32 的工作模式，该寄存器保存着复位后 bootstrap 引脚的电平状态。根据不同的复位原因，程序会执行不同的操作：

从深度睡眠模式复位：如果 RTC_CNTL_STORE6_REG 寄存器的值非零，并且 RTC_CNTL_STORE7_REG 寄存器中的 RTC 内存的 CRC 校验值有效，那么程序会使用 RTC_CNTL_STORE6_REG 寄存器的值作为入口地址，并立即跳转到该地址运行。如果 RTC_CNTL_STORE6_REG 的值为零，或者 RTC_CNTL_STORE7_REG 中的 CRC 校验值无效，又或者跳转到 RTC_CNTL_STORE6_REG 地址处运行的程序返回，那么将会执行上电复位的相关操作。 注意 ：如果想在这里运行自定义的代码，可以参考 :doc:`深度睡眠 ` 文档里面介绍的方法。

上电复位、软件 SoC 复位、看门狗 SoC 复位：检查 GPIO_STRAP_REG 寄存器，判断是否 UART 或 SDIO 请求进入下载模式。如果是，则配置好 UART 或者 SDIO，然后等待下载代码。否则程序将会执行软件 CPU 复位的相关操作。

软件 CPU 复位、看门狗 CPU 复位：根据 EFUSE 中的值配置 SPI Flash，然后尝试从 Flash 中加载代码，这部分的内存将会在后面一小节详细介绍。如果从 Flash 中加载代码失败，就会将 BASIC 解析器加压缩到 RAM 中启动。需要注意的是，此时 RTC 看门狗还在使能状态，如果在几百毫秒内没有任何输入事件，那么看门狗会再次复位 SoC，重复整个过程。如果解析器收到了来自 UART 的输入，程序会关闭看门狗。

应用程序的二进制镜像会从 Flash 的 0x1000 地址处加载。Flash 的第一个 4kB 扇区用于存储安全引导程序和应用程序镜像的签名。有关详细信息，请查看安全启动文档。

二级引导程序

在 ESP-IDF 中，存放在 Flash 的 0x1000 偏移地址处的二进制镜像就是二级引导程序。二级引导程序的源码可以在 ESP-IDF 的 components/bootloader 目录下找到。请注意，对于 ESP32 芯片来说，这并不是唯一的安排程序镜像的方式。事实上用户完全可以把一个功能齐全的应用程序烧写到 Flash 的 0x1000 偏移地址处运行，但这超出本文档的范围。ESP-IDF 使用二级引导程序可以增加 Flash 分区的灵活性(使用分区表)，并且方便实现 Flash 加密，安全引导和空中升级(OTA)等功能。

当一级引导程序校验并加载完二级引导程序后，它会从二进制镜像的头部找到二级引导程序的入口点，并跳转过去运行。

二级引导程序从 Flash 的 0x8000 偏移地址处读取分区表。详细信息请参阅分区表文档 :doc:`分区表 ` 。二级引导程序会寻找出厂分区和 OTA 分区，然后根据 OTA 信息 分区的数据决引导哪个分区。

对于选定的分区，二级引导程序将映射到 IRAM 和 DRAM 的数据和代码段复制到它们的加载地址处。对于一些加载地址位于 DROM 和 IROM 区域的段，会通过配置 Flash MMU 为其提供正确的映射。请注意，二级引导程序会为 PRO CPU 和 APP CPU 都配置 Flash MMU，但它只使能了 PRO CPU 的 Flash MMU。这么做的原因在于二级引导程序的代码被加载到了 APP CPU 的高速缓存使用的内存区域，因此使能 APP CPU 高速缓存的任务就交给了应用程序。一旦代码加载完毕并且设置好 Flash MMU，二级引导程序会从应用程序二进制镜像文件的头部寻找入口地址，然后跳转到该地址处运行。

目前还不支持添加钩子函数到二级引导程序中以自定义应用程序分区选择的逻辑，但是可以通过别的途径实现这个需求，比如根据某个 GPIO 的不同状态来引导不同的应用程序镜像。此类自定义的功能将在未来添加到 ESP-IDF 中。目前，可以通过将 bootloader 组件复制到应用程序目录并在那里进行必要的更改来自定义引导程序。在这种情况下，ESP-IDF 的编译系统将编译应用程序目录中的组件而不是 ESP-IDF 组件目录。

应用程序启动阶段

ESP-IDF 应用程序的入口是 components/esp32/cpu_start.c 文件中的 call_start_cpu0 函数，该函数主要完成了两件事，一是启用堆分配器，二是使 APP CPU 跳转到其入口点—— call_start_cpu1 函数。PRO CPU 上的代码会给 APP CPU 设置好入口地址，解除其复位状态，然后等待 APP CPU 上运行的代码设置一个全局标志，以表明 APP CPU 已经正常启动。 完成后，PRO CPU 跳转到 start_cpu0 函数，APP CPU 跳转到 start_cpu1 函数。

start_cpu0 和 start_cpu1 这两个函数都是弱类型的，这意味着如果某些特定的应用程序需要修改初始化顺序，就可以通过重写这两个函数来实现。 start_cpu0 默认的实现方式是初始化用户在 menuconfig 中选择的组件，具体实现步骤可以阅读 components/esp32/cpu_start.c 文件中的源码。请注意，此阶段会调用应用程序中存在的 C++ 全局构造函数。一旦所有必要的组件都初始化好，就会创建 main task ，并启动 FreeRTOS 的调度器。

当 PRO CPU 在 start_cpu0 函数中进行初始化的时候，APP CPU 在 start_cpu1 函数中自旋，等待 PRO CPU 上的调度器启动。一旦 PRO CPU 上的调度器启动后，APP CPU 上的代码也会启动调度器。

主任务是指运行 app_main 函数的任务，主任务的堆栈大小和优先级可以在 menuconfig 中进行配置。应用程序可以用此任务来完成用户程序相关的初始化设置，比如启动其他的任务。应用程序还可以将主任务用于事件循环和其他通用活动。如果 app_main 函数返回，那么主任务将会被删除。

应用程序的内存布局

ESP32 芯片具有灵活的内存映射功能，本小节将介绍 ESP-IDF 默认使用这些功能的方式。

ESP-IDF 应用程序的代码可以放在以下内存区域之一。

IRAM(指令 RAM)

ESP-IDF 将内部 SRAM0 区域(在技术参考手册中有定义)的一部分分配为指令 RAM。除了开始的 64kB 用作 PRO CPU 和 APP CPU 的高速缓存外，剩余内存区域(从 0x40080000 至 0x400A0000 )被用来存储应用程序中部分需要在RAM中运行的代码。

一些 ESP-IDF 的组件和 WiFi 协议栈的部分代码通过链接脚本文件被存放到了这块内存区域。

如果一些应用程序的代码需要放在 IRAM 中运行，可以使用 IRAM_ATTR 宏定义进行声明。

#include "esp_attr.h"

void IRAM_ATTR gpio_isr_handler(void* arg)

{

// ...

}

下面列举了应用程序中可能或者应该放入 IRAM 中运行例子。

当注册中断处理程序的时候设置了 ESP_INTR_FLAG_IRAM ，那么中断处理程序就必须要放在 IRAM 中运行。这种情况下，ISR 只能调用存放在 IRAM 或者 ROM 中的函数。 注意 ：目前所有 FreeRTOS 的 API 都已经存放到了 IRAM 中，所以在中断中调用 FreeRTOS 的中断专属 API 是安全的。如果将 ISR 放在 IRAM 中运行，那么必须使用宏定义 DRAM_ATTR 将该 ISR 用到所有常量数据和调用的函数(包括但不限于 const char 数组)放入 DRAM 中。

可以将一些时间关键的代码放在 IRAM 中，这样可以缩减从 Flash 加载代码所消耗的时间。ESP32 是通过 32kB 的高速缓存来从外部 Flash 中读取代码和数据的，将函数放在 IRAM 中运行可以减少由高速缓存未命中引起的时间延迟。

毋庸置疑，不建议在 ISR 中使用 printf 和其余输出函数。出于调试的目的，可以在 ISR 中使用 ESP_EARLY_LOGx 来输出日志，不过要确保将 TAG 和格式字符串都放在了 DRAM 中。

小结：

首先ESP32是双核CPU，分别是PRO CPU 和 APP CPU。平时都是PRO CPU在跑，APP CPU围观(保持复位)。

然后ESP32有两个引导程序BootLoader。最后就是ESP32所谓应用程序就是FreeRTOS.

1、Soc复位后，PRO CPU 会立即开始运行复位向量代码，APP CPU围观。开始执行BootLoader1，BootLoader1的目的是从 Flash 的 0x1000 地址处加载BootLoader2到RAM.

2、BootLoader2从 Flash 的 0x8000 偏移地址处读取分区表，会通过配置 Flash MMU 为其提供正确的映射。为 PRO CPU 和 APP CPU 都配置 Flash MMU，但它只使能了 PRO CPU 的 Flash MMU，此时APP CPU保持围观。一旦代码加载完毕并且设置好 Flash MMU，就会从跳转执行应用程序，分区表有应用程序的地址，如下所示。

3、initArduino()初始化FreeRTOS,   xTaskCreatePinnedToCore开始创建PRO CPU的任务loopTask，可以看到任务调用了setup() 和  loop()函数。

ESP32程序上传过程：

esptool.py v2.1-beta1

Connecting....

Chip is ESP32D0WDQ6 (revision (unknown 0xa))

Uploading stub...

Running stub...

Stub running...

Changing baud rate to 921600

Changed.

Configuring flash size...

Auto-detected Flash size: 4MB

Compressed 8192bytes to 47...

Writing at 0x0000e000... (100 %)

Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.0 seconds (effective 9362.3 kbit/s)...

Hash of data verified.

Compressed 10464bytes to 7012...

Writing at 0x00001000... (100 %)

Wrote 10464 bytes (7012 compressed) at 0x00001000 in 0.1 seconds (effective 973.4 kbit/s)...

Hash of data verified.

Compressed 288720bytes to 183136...

Writing at 0x00010000... (8 %)

Writing at 0x00014000... (16 %)

Writing at 0x00018000... (25 %)

Writing at 0x0001c000... (33 %)

Writing at 0x00020000... (41 %)

Writing at 0x00024000... (50 %)

Writing at 0x00028000... (58 %)

Writing at 0x0002c000... (66 %)

Writing at 0x00030000... (75 %)

Writing at 0x00034000... (83 %)

Writing at 0x00038000... (91 %)

Writing at 0x0003c000... (100 %)

Wrote 288720 bytes (183136 compressed) at 0x00010000 in 2.5 seconds (effective 928.7 kbit/s)...

Hash of data verified.

Compressed 3072bytes to 122...

Writing at 0x00008000... (100 %)

Wrote 3072 bytes (122 compressed) at 0x00008000 in 0.0 seconds (effective 3071.9 kbit/s)...

Hash of data verified.

Leaving...

Hard resetting...

0x0000e000 写了8192 bytes  boot_app0.bin

0x00001000 写了10464 bytes bootloader.bin

0x00010000 写了288720 bytes app0

0x00008000 写了3072 bytes default.bin通过default.csv生成