企业官网建设流程全解析

1. 项目概述：为什么HC32F460的串口IAP值得花时间深挖？

华大半导体HC32F460系列是国产32位MCU中少有的、在工业控制与智能终端领域真正实现“性能-成本-生态”三平衡的主力型号。它基于ARM Cortex-M4F内核，主频高达200MHz，带FPU和DSP指令集，片上集成512KB Flash、192KB SRAM，还具备丰富的外设资源——尤其是双路独立UART（支持DMA+硬件流控）、灵活的Flash分页管理机制（最小擦除单位为2KB扇区）、以及关键的BootROM固化功能。这些特性共同构成了一个可工程化落地的串口IAP升级体系的基础。但现实是，很多工程师拿到HC32F460开发板后，第一反应是“先跑个LED闪烁”，第二反应是“串口打印调试信息”，第三反应往往是“怎么把新固件发上去？”——然后卡在BootLoader跳转失败、APP校验不通过、Flash擦写异常等环节，反复烧录、反复断电、反复怀疑人生。我去年在给一家工业温控设备做固件远程维护方案时，就踩过整整三周的坑：从最初用ST-Link硬烧APP导致BootLoader被覆盖，到后来发现HC32F460的Flash保护寄存器（FLASH_PROT）默认是开启状态，再到最终定位到串口接收缓冲区溢出引发的帧同步丢失……这些都不是文档里明说的“注意事项”，而是实打实的产线级经验。所以这篇内容不是教你怎么“看懂IAP概念”，而是直接带你从零开始，手把手搭出一个能稳定运行、可量产部署、带完整错误恢复机制的BootLoader+APP双分区系统。它适合三类人：一是刚接触华大MCU的嵌入式新人，需要一份避开所有已知雷区的实操指南；二是已有项目在用HC32F460但升级功能不稳定的工程师，可以对照排查；三是负责固件架构设计的技术负责人，需要理解底层Flash映射、向量表重定向、CRC校验策略等关键决策点。核心关键词——华大、HC32F460、串口、IAP、BootLoader——每一个都对应着一个必须亲手验证的硬核环节，而不是调用几个API就能糊弄过去的。

2. 整体架构设计与关键决策逻辑

2.1 为什么必须严格划分BootLoader与APP的Flash空间？

HC32F460的512KB Flash不是一块均匀的“大硬盘”，而是由多个物理扇区（Sector）组成的阵列，每个扇区大小为2KB。官方数据手册明确指出：Flash擦除操作以扇区为最小单位，且擦除后所有位变为0xFF。这意味着，如果你把BootLoader和APP混放在同一扇区，哪怕只改APP里一行代码，整个扇区都要擦除——而BootLoader一旦被擦掉，设备就彻底变砖，再也无法启动。因此，第一步必须做的是物理空间隔离。我们采用经典的“双Bank”布局：前64KB（0x00000000–0x0000FFFF）留给BootLoader，剩余448KB（0x00010000–0x0007FFFF）给APP。这个64KB不是拍脑袋定的，而是经过精确计算的结果：HC32F460的BootROM启动流程要求复位向量表必须位于Flash起始地址（0x00000000），而BootLoader本身需要包含UART驱动、Flash擦写函数、CRC校验模块、跳转逻辑等，经Keil MDK编译后实际占用约42KB（含保留的中断向量表备份区）。留出64KB，既保证了未来功能扩展余量，又避开了HC32F460特有的“Flash保护寄存器配置区”（位于0x0000F800–0x0000F8FF），这个区域一旦误写会导致整片Flash锁死，必须用专用解锁工具才能恢复。很多人图省事把BootLoader塞进前32KB，结果在调试阶段频繁触发保护锁死，白白浪费两天时间。所以，空间划分不是技术选型，而是安全底线。

2.2 串口IAP为什么不选USB或CAN，而坚持用UART？

网络热词里出现大量“USB转串口”“CH340驱动”“虚拟串口软件”，恰恰说明UART是IAP最普适、最低成本的物理通道。USB协议栈复杂，HC32F460虽支持USB Device，但需额外移植USB协议栈（如TinyUSB），且USB枚举失败率高，尤其在工控现场电磁干扰强的环境下；CAN总线成本高（需收发器芯片+隔离电路），且协议解析开销大，对小体积终端不友好。而UART的优势在于：第一，HC32F460原生支持两路独立UART，其中UART0（PA0/PA1）默认复位后即启用，无需额外初始化；第二，串口通信本质是字节流，天然适配固件二进制文件的逐块传输；第三，物理层极其简单——一根TX、一根RX、一根GND，用CH340或CP2102这类成熟方案，成本不到2元，且驱动兼容性极好（Windows/Linux/macOS全支持）。我们实测过，在波特率115200下，传输128KB固件耗时约12秒，完全满足现场维护需求。更重要的是，UART的“不可靠性”反而倒逼出更健壮的协议设计：没有ACK/NACK机制、没有自动重传、没有流量控制（除非启用RTS/CTS），这就要求我们在应用层必须实现完整的帧头校验、包序号管理、超时重传、断点续传。这种“被迫严谨”恰恰是工业级IAP的核心价值——它让系统在弱网、干扰、意外断电等恶劣条件下依然能完成升级。

2.3 BootLoader启动流程的三个不可绕过阶段

HC32F460的启动不是简单的“从0x00000000取PC值”，而是一个多阶段引导过程，理解它才能避免跳转失败：

1. BootROM阶段（硬件强制）：芯片上电后，首先执行片内BootROM代码。它会检测BOOT引脚（PB13）电平：低电平则从Flash启动（走我们的BootLoader路径），高电平则从SRAM启动（用于调试）。这个阶段不可编程，但决定了后续流程走向。

2. BootLoader阶段（用户代码）：若从Flash启动，BootROM会将PC指向0x00000000，即我们烧录的BootLoader首地址。此时BootLoader必须完成三件事：a) 初始化系统时钟（必须先于任何外设）；b) 初始化UART0（波特率、停止位、校验位需与上位机严格一致）；c) 检查APP区首地址（0x00010000）是否有效——这里不是读取APP代码，而是读取该地址处的栈顶指针值（即APP的初始SP）。根据ARM Cortex-M规范，栈顶指针必须落在SRAM范围内（0x20000000–0x2002FFFF），且不能为0或0xFFFFFFFF。如果SP非法，说明APP未烧录或损坏，BootLoader应进入等待升级模式；如果SP合法，则跳转到APP复位向量（0x00010004处的字）。

3. APP阶段（用户应用）：APP启动后，第一件事不是执行main()，而是重映射中断向量表。因为APP的向量表在0x00010000，而CM4内核默认从0x00000000读取，所以必须执行SCB->VTOR = 0x00010000;。这一步漏掉，任何中断（包括SysTick）都会触发HardFault。我们曾遇到一个案例：APP能跑通，但定时器中断不响应，查了三天才发现VTOR没设置——这种细节，官方例程里往往一笔带过，但产线设备一出问题就是致命伤。

3. 核心细节解析与实操要点

3.1 BootLoader工程配置：Keil MDK下的三个关键设置

在Keil uVision5中创建BootLoader工程，绝不是新建一个空项目那么简单。以下是三个决定成败的配置项，缺一不可：

第一，分散加载文件（Scatter File）的精确编写
HC32F460的Flash起始地址是0x00000000，但BootLoader不能占用全部空间。我们创建bootloader_scatter.sct文件，内容如下：

LR_IROM1 0x00000000 0x00010000 { ; load region size_region ER_IROM1 0x00000000 0x00010000 { ; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } RW_IRAM1 0x20000000 UNINIT 0x00008000 { ; 32KB RAM for stack/heap .ANY (+RW +ZI) } }

关键点在于：ER_IROM1的长度设为0x00010000（64KB），且*.o (RESET, +First)确保复位向量表永远放在最开头。如果这里写成0x00000000 0x00008000（32KB），编译器会把代码塞进前32KB，但BootROM仍会从0x00000000读取，导致向量表错位。

第二，启动文件（startup_hc32f460.s）的修改
官方启动文件默认将栈顶指针（SP）设为__initial_sp，这是链接器生成的符号。但在BootLoader中，我们必须确保SP初始化正确。找到.stack段定义，将其改为：

Stack_Size EQU 0x00000400 ; 1KB stack for bootloader AREA STACK, NOINIT, READWRITE, ALIGN=3 Stack_Mem SPACE Stack_Size __initial_sp EQU Stack_Mem + Stack_Size

同时，在Reset_Handler入口处，手动加载SP：

Reset_Handler PROC EXPORT Reset_Handler [WEAK] IMPORT SystemInit IMPORT __main LDR SP, =__initial_sp ; critical: set stack pointer first! BL SystemInit BL __main END

如果不显式加载SP，某些调试器（如J-Link）可能用默认SP，导致BootLoader运行时栈溢出。

第三，Flash擦写函数的原子性保障
HC32F460的Flash控制器（FLASHC）要求：擦除前必须关闭全局中断（__disable_irq()），擦除后重新使能（__enable_irq()）。这是因为擦除操作耗时约20ms，期间若有中断打断，可能导致Flash状态机紊乱。我们封装的擦除函数如下：

uint32_t Flash_Erase_Sector(uint32_t sector_addr) { uint32_t status = FLASH_OK; __disable_irq(); // 必须！ FLASHC->CR = FLASH_CR_PER; // 设置擦除模式 FLASHC->AR = sector_addr; // 设置目标扇区地址 FLASHC->CR = FLASH_CR_SER | FLASH_CR_STRT; // 启动擦除 while(FLASHC->SR & FLASH_SR_BSY); // 等待忙标志清零 if(FLASHC->SR & FLASH_SR_EOP) { FLASHC->SR = FLASH_SR_EOP; // 清除EOP标志 } else { status = FLASH_ERROR; } __enable_irq(); // 必须！ return status; }

曾有同事在擦除函数里忘了关中断，结果UART接收中断在擦除过程中触发，导致串口接收缓冲区被破坏，升级包校验失败——这种问题极难复现，但一旦发生，设备就永久性无法升级。

3.2 IAP通信协议设计：为什么不用XMODEM而自研轻量协议？

网上教程常推荐XMODEM或YMODEM协议，但它们在HC32F460上存在严重水土不服：XMODEM每包128字节，需3次握手（SOH/ACK/NAK），在115200波特率下，单包传输加等待耗时约15ms，128KB固件需1024包，理论耗时15秒，但实际因NAK重传、串口缓冲区溢出等问题，经常卡在80%进度。我们设计了一个极简的“帧-确认”协议，仅4个字段：

| SOF(0xAA) | LEN(1B) | CMD(1B) | DATA(NB) | CRC(2B) |

• SOF：帧起始标志，避免误触发；
• LEN：数据长度（0–255字节），最大包长设为240字节（留2字节给CMD+CRC）；
• CMD：命令码，0x01=请求升级，0x02=固件数据，0x03=升级完成；
• DATA：固件数据块，按Flash扇区对齐（2KB）分块传输；
• CRC：Modbus CRC16校验，比累加和更可靠。

协议优势在于：单帧处理逻辑极简，无状态机复杂度。BootLoader收到一帧，先校验SOF和CRC，正确则写入RAM缓冲区，立即回传ACK（单字节0x06），上位机收到ACK即发下一帧。实测在115200波特率下，240字节帧平均耗时22ms（含ACK往返），128KB固件仅需534帧，总耗时约11.7秒，且无重传——因为CRC校验失败时，BootLoader直接丢弃该帧，上位机超时（500ms）后重发，逻辑清晰可控。更重要的是，这个协议可无缝迁移到其他MCU，只需改CRC算法和UART驱动，无需重写状态机。

3.3 APP工程的关键改造：向量表重映射与Flash保护解除

APP工程看似独立，但若不做针对性改造，BootLoader跳转后必然崩溃。核心改造有两点：

向量表重映射（VTOR设置）
在APP的main()函数最开头，必须执行：

// 将中断向量表重映射到APP区起始地址 SCB->VTOR = 0x00010000UL; // APP的向量表在0x00010000 __DSB(); // 数据同步屏障，确保VTOR写入生效 __ISB(); // 指令同步屏障，刷新流水线

这个操作必须在任何中断使能（如NVIC_EnableIRQ()）之前完成。否则，SysTick或UART中断触发时，内核仍会从0x00000000读取向量，导致跳转到BootLoader代码区，引发不可预测行为。

Flash保护寄存器（FLASH_PROT）的动态解除
HC32F460出厂默认开启Flash写保护，寄存器地址为0x0000F800。APP若需自行升级（如OTA），必须在运行时解除保护。方法是向该地址写入特定密钥序列：

// 解除Flash写保护（需在APP中调用） void Flash_Unlock(void) { FLASHC->KEYR = 0x45670123UL; // 第一密钥 FLASHC->KEYR = 0xCDEF89ABUL; // 第二密钥 // 此时FLASH_PROT寄存器可写 FLASHC->PROT = 0x00000000UL; // 全部解除保护 }

注意：此操作只能在APP中执行，BootLoader中执行会导致BootLoader自身被擦除。我们曾因在BootLoader里调用Flash_Unlock()，结果升级时误擦除了BootLoader扇区，设备变砖——这个教训刻骨铭心。

4. 实操过程与核心环节实现

4.1 BootLoader开发：从UART接收、Flash擦写到跳转的全流程

现在进入真正的编码环节。以下代码基于HC32F460 SDK v2.0.0，使用标准外设库，所有函数均可直接编译。

第一步：UART0初始化（波特率115200，8N1）

void UART0_Init(void) { stc_gpio_init_t stcGpioInit; DDL_ZERO_STRUCT(stcGpioInit); // 使能GPIOA和UART0时钟 Sysctrl_SetPeripheralGate(SysctrlPeripheralGpioA, TRUE); Sysctrl_SetPeripheralGate(SysctrlPeripheralUart0, TRUE); // PA0/PA1复用为UART0_TX/RX stcGpioInit.u16Pin = GPIO_PIN_0 | GPIO_PIN_1; stcGpioInit.u16PinsMode = GPIO_MODE_AF_PP; stcGpioInit.u16PinsPuPd = GPIO_PUPD_UP; Gpio_Init(GPIOA, &stcGpioInit); // 配置UART0 stc_uart_init_t stcUartInit; DDL_ZERO_STRUCT(stcUartInit); stcUartInit.u32BaudRate = 115200UL; stcUartInit.u32DataWidth = UART_DATA_WIDTH_8BIT; stcUartInit.u32StopBit = UART_STOP_BIT_1; stcUartInit.u32Parity = UART_PARITY_NONE; Uart_Init(M4_USART0, &stcUartInit); // 使能UART0接收中断 Uart_ClrStatus(M4_USART0, UART_INT_RX); Uart_IntCmd(M4_USART0, UART_INT_RX, TRUE); NVIC_ClearPendingIRQ(UART0_IRQn); NVIC_EnableIRQ(UART0_IRQn); }

关键点：GPIO_PUPD_UP上拉电阻必须启用，否则RX引脚悬空易受干扰；Uart_IntCmd()必须在Uart_Init()之后调用，顺序颠倒会导致中断不触发。

第二步：UART接收中断服务程序（ISR）

__attribute__((interrupt("WCH-Interrupt-fast"))) void UART0_IRQHandler(void) { uint8_t u8Data; static uint8_t au8RxBuffer[256]; // 接收缓冲区 static uint16_t u16RxIndex = 0; static uint8_t u8SofFlag = 0; // 读取接收数据 if (TRUE == Uart_GetStatus(M4_USART0, UART_FLAG_RX)) { u8Data = Uart_ReceiveData(M4_USART0); if (u8SofFlag == 0 && u8Data == 0xAA) { u8SofFlag = 1; u16RxIndex = 0; } else if (u8SofFlag == 1) { if (u16RxIndex < sizeof(au8RxBuffer)) { au8RxBuffer[u16RxIndex++] = u8Data; if (u16RxIndex >= 3) { // 至少收到SOF+LEN+CMD uint8_t u8Len = au8RxBuffer[1]; uint8_t u8CrcHigh = au8RxBuffer[u16RxIndex-2]; uint8_t u8CrcLow = au8RxBuffer[u16RxIndex-1]; uint16_t u16Crc = (u8CrcHigh << 8) | u8CrcLow; uint16_t u16CalcCrc = Crc16_Modbus(au8RxBuffer, u16RxIndex-2); if (u16CalcCrc == u16Crc) { Iap_ProcessFrame(au8RxBuffer, u16RxIndex); u8SofFlag = 0; // 处理完一帧，重置 } } } } } }

这里用了一个技巧：不依赖UART的“接收完成中断”，而是用“接收数据就绪中断”，实时捕获每个字节。这样能精准控制帧同步，避免因波特率误差导致的帧错位。

第三步：IAP帧处理函数（核心逻辑）

typedef struct { uint32_t u32AppAddr; // APP起始地址 uint32_t u32AppSize; // APP大小（字节） uint8_t au8AppBuf[2048]; // 2KB缓冲区，对应一个Flash扇区 uint16_t u16BufIndex; // 当前缓冲区写入位置 } stc_iap_t; static stc_iap_t m_stcIap; void Iap_ProcessFrame(uint8_t *pu8Frame, uint16_t u16Len) { uint8_t u8Cmd = pu8Frame[2]; uint8_t u8Len = pu8Frame[1]; switch(u8Cmd) { case 0x01: // 请求升级 // 清空APP区，准备接收 m_stcIap.u32AppAddr = 0x00010000UL; m_stcIap.u32AppSize = 0UL; m_stcIap.u16BufIndex = 0; Uart_SendData(M4_USART0, 0x06); // ACK break; case 0x02: // 固件数据 if (u8Len <= 240) { // 将数据拷贝到缓冲区 memcpy(&m_stcIap.au8AppBuf[m_stcIap.u16BufIndex], &pu8Frame[3], u8Len); m_stcIap.u16BufIndex += u8Len; // 缓冲区满2KB，写入Flash if (m_stcIap.u16BufIndex >= 2048) { Flash_Erase_Sector(m_stcIap.u32AppAddr); Flash_Write(m_stcIap.u32AppAddr, m_stcIap.au8AppBuf, 2048); m_stcIap.u32AppAddr += 2048; m_stcIap.u32AppSize += 2048; m_stcIap.u16BufIndex = 0; } Uart_SendData(M4_USART0, 0x06); // ACK } break; case 0x03: // 升级完成 // 写入APP大小到特定地址（如0x0000F000），供BootLoader校验 Flash_Erase_Sector(0x0000F000UL); Flash_Write(0x0000F000UL, (uint8_t*)&m_stcIap.u32AppSize, 4); Uart_SendData(M4_USART0, 0x06); // 延时100ms，确保ACK发出 Ddl_Delay1ms(100); // 跳转到APP Jump_To_App(0x00010000UL); break; } }

Jump_To_App()函数是最后一步：

typedef void (*pFunction)(void); void Jump_To_App(uint32_t app_addr) { pFunction Jump_To_Application; uint32_t *jump_address; // 关闭所有中断 __disable_irq(); // 清空Cache（如有） SCB_InvalidateICache(); SCB_InvalidateDCache(); // 获取APP的栈顶指针 jump_address = (uint32_t*)app_addr; __set_MSP(*jump_address); // 设置主堆栈指针 // 获取APP的复位向量 Jump_To_Application = (pFunction)(*(jump_address + 1)); // 执行跳转 Jump_To_Application(); }

注意：__set_MSP()必须在Jump_To_Application()之前调用，否则APP启动时栈指针错误。

4.2 上位机工具开发：用Python写一个可靠的串口升级助手

既然协议是自研的，上位机也必须自己写。我们用Python+PySerial实现，核心逻辑如下：

import serial import time import sys import os def send_frame(ser, cmd, data=b''): """发送一帧数据""" frame = bytearray([0xAA, len(data), cmd]) frame.extend(data) crc = calc_crc16(frame[:-2]) # 计算CRC16 frame.append((crc >> 8) & 0xFF) frame.append(crc & 0xFF) ser.write(frame) # 等待ACK start_time = time.time() while time.time() - start_time < 0.5: if ser.in_waiting > 0: ack = ser.read(1) if ack == b'\x06': return True return False def upgrade_firmware(ser, firmware_path): """执行固件升级""" with open(firmware_path, 'rb') as f: fw_data = f.read() # 步骤1：发送升级请求 if not send_frame(ser, 0x01): print("Error: No ACK for upgrade request") return False # 步骤2：分块发送固件 block_size = 240 for i in range(0, len(fw_data), block_size): block = fw_data[i:i+block_size] if not send_frame(ser, 0x02, block): print(f"Error: Failed to send block {i//block_size}") return False # 进度显示 progress = min(100, int((i + len(block)) / len(fw_data) * 100)) print(f"\rUpgrading... {progress}%", end='') # 步骤3：发送升级完成命令 if not send_frame(ser, 0x03): print("\nError: No ACK for upgrade complete") return False print("\nUpgrade success!") return True if __name__ == "__main__": if len(sys.argv) != 3: print("Usage: python iap_tool.py <COMx> <firmware.bin>") sys.exit(1) try: ser = serial.Serial(sys.argv[1], 115200, timeout=1) upgrade_firmware(ser, sys.argv[2]) ser.close() except Exception as e: print(f"Error: {e}")

这个工具的优势在于：纯Python，跨平台（Windows/Linux/macOS），无GUI依赖，可直接集成到自动化测试脚本中。我们实测过，在Windows下用CH340驱动，Linux下用CP2102驱动，均能100%成功升级。关键技巧是：timeout=1避免串口阻塞；send_frame()里的0.5秒超时足够覆盖UART传输延迟；进度条实时反馈，让现场工程师心里有底。

4.3 烧录与调试：如何用J-Link烧录BootLoader并验证

烧录不是简单地“Load File”，而是有严格顺序：

第一步：擦除整个Flash
用J-Link Commander连接HC32F460，执行：

connect erase all

这一步必须做，因为旧固件可能残留保护位，导致后续烧录失败。

第二步：烧录BootLoader到0x00000000
在Keil中编译BootLoader，生成bootloader.hex。在J-Link Commander中：

loadfile bootloader.hex 0x00000000

烧录完成后，用mem32 0x00000000 4查看前4字节，应为栈顶指针值（如0x20020000），确认向量表正确。

第三步：验证BootLoader功能
断开J-Link，用CH340模块连接UART0，打开串口助手（如XCOM），设置115200,8N1。发送十六进制AA 00 01 00 00（请求升级帧），应收到06作为ACK。若无响应，检查：a) BOOT引脚是否接地；b) CH340供电是否稳定（需3.3V）；c) 串口线TX/RX是否接反。

第四步：烧录APP（仅用于首次测试）
用J-Link烧录一个最小APP（如LED闪烁），地址从0x00010000开始：

loadfile app.hex 0x00010000

然后断电重启，观察LED是否闪烁。若闪烁，说明BootLoader跳转成功；若不闪烁，用J-Link抓取HardFault，大概率是VTOR没设置。

5. 常见问题与排查技巧实录

5.1 串口烧写失败的四大高频原因及速查表

我们曾遇到一个典型问题：客户现场用USB转TTL模块（非CH340），升级时总是卡在第32768字节（刚好是32KB）。查了两天，最后发现该模块的TX引脚驱动能力不足，在长距离（>1米）线缆下信号畸变，导致BootLoader误判CRC。解决方案是换用CH340模块，或在线缆两端加120Ω终端电阻——这种硬件级问题，光看代码永远找不到。

5.2 BootLoader跳转失败的硬核调试法

当Jump_To_App()执行后设备无响应，不要急着重烧，按以下顺序排查：

第一，确认跳转地址正确
在Jump_To_App()函数开头添加调试输出：

printf("Jump addr: 0x%08X\r\n", app_addr); printf("MSP: 0x%08X\r\n", *jump_address); printf("Reset Vec: 0x%08X\r\n", *(jump_address + 1));

用SWD接口连接J-Link，打开J-Link RTT Viewer，查看输出。若MSP为0或Reset Vec为0，说明APP区未正确烧录，或APP的__initial_sp链接错误。

第二，检查Flash擦写是否完整
用J-Link Commander读取APP区前16字节：

mem32 0x00010000 4

正常应为栈顶指针（如0x20020000），若为0xFFFFFFFF，说明该扇区未擦除；若为乱码，说明擦除后写入失败。

第三，验证APP的复位向量
APP的startup_hc32f460.s中，__initial_sp必须正确定义。常见错误是链接脚本里LR_IROM1起始地址写错，导致向量表偏移。用fromelf --text -c app.axf反汇编，确认0x00010000处确实是栈顶指针值。

5.3 生产环境避坑指南：三个被忽略却致命的细节

细节一：BootLoader必须禁用看门狗（WDT）
HC32F460的WDT默认使能，超时时间约2.1秒。BootLoader若在UART接收等待中耗时过长（如用户迟迟不发升级包），WDT会复位芯片，导致反复重启。解决方案是在BootLoader初始化后立即关闭：

// 关闭看门狗 Wdt_DeInit();

这个操作必须在UART0_Init()之后、主循环之前执行。

细节二：APP区首地址必须对齐2KB
虽然Flash扇区是2KB，但APP代码的起始地址（0x00010000）必须严格对齐。若在Keil中设置IRAM1起始地址为0x00010001，链接器会把向量表塞进0x00010001，导致BootLoader读取的SP值错误。务必在分散加载文件中写死：

ER_IROM2 0x00010000 0x00070000 { ; APP region *.