1. 先还原事故现场跳转成功但中断集体失灵的典型症状1.1 一个让我折腾了两天的产线问题去年有一批设备的IAP固件升级方案release之后产线反馈升级死机率接近三成。现场拿回来的板子接上J-Link一切正常程序能跑到main串口也能正常打印但只要彻底断电再上电就卡死。盯着调试器看了两天最后问题指向中断向量表重映射。这个现象在IAP项目里非常典型升级流程本身走通了Boot跳转也“成功”了但APP运行后外设中断全部不响应。UART收不到数据、定时器不跑、按键扫描没反应整个系统看起来像“假死”——其实CPU在主循环里活着只是中断进不去。很多工程师遇到这种情况的第一反应是怀疑APP的初始化代码有问题或者优化等级配置错了于是反复改启动文件、调链接脚本甚至怀疑是芯片本身的问题。但我建议先冷静下来把故障现象拆开看主循环能跑说明PC指针已经在APP代码段里正常执行CPU没有死锁也没有进HardFault中断不响应说明中断发生时CPU去取向量表的位置出了问题。1.2 症状归纳能跑主循环却进不了任何中断我把这类问题按照表现形态归了三类你可以直接对照你手里的设备故障表现可能的根因方向升级后死机复位后能重新进入Boot但进不了APP跳转地址错误或者APP的Reset_Handler没有被正确取到能进APP的main但UART、SysTick、外部中断全部无响应中断向量表仍在旧位置中断发生后取到的是Boot区向量或全F地址偶尔正常偶尔死机断电重启后概率更高VTOR对齐不对、RAM向量表初始化不及时、外设中断在跳转前残留第一类问题通常比较好查检查App基址处的栈顶指针和复位向量即可。最阴险的是第二类因为它表面上看“程序已经跑起来”仿真器里也能看到main函数在执行但实际中断路径是坏的。第三类则是前两类的变体往往藏着更隐蔽的时序问题。我在那次排查里还记录了一个关键细节死机设备按复位键之后如果立刻进Boot并且重新做一次升级流程设备又能恢复正常。这个现象说明Boot本身没问题Flash内容也没问题问题出在“上电后中断向量表没有被正确引导到APP区”。1.3 为什么仿真器“帮倒忙”这里要特别提醒一句仿真器正常不代表真机正常。调试器在连接目标板时通常会在内核复位后把PC设置到调试入口很多调试器还会在attach时顺手把VTOR相关的状态保持住。也就是说你在仿真器里看到的“复位后正常跑通”可能已经是调试器帮你纠正过一遍的状态。另外调试状态下RAM里的变量值往往保留了上一次运行的残影。如果你把升级标志存在RAM里调试器复位不会清RAM自然能跑通但产品断电再上电RAM全部归零Bug就在这一刻暴露。这也是我后来坚持“凡是IAP相关的bug先拔掉调试器冷启动复现”的原因。2. 重映射的底层逻辑CPU复位后到底去哪里拿第一条指令2.1 向量表的原始用途和启动取指过程要理解重映射得先回到Cortex-M的启动瞬间。以Cortex-M3/M0为例CPU上电后做的事其实非常简单从地址0x00000000读取栈顶指针MSP初值从地址0x00000004读取复位向量Reset_Handler地址跳转到Reset_Handler开始执行。这两个值并不是放在寄存器里的而是放在中断向量表的最开头。向量表本质上是一个以函数指针为元素的数组[0]是MSP[1]是Reset[2]是NMI[3]是HardFault之后依次是各外设的中断入口。当任何一个中断发生时NVIC会根据中断号去向量表里找对应的入口地址然后压栈、跳转。所以“向量表在哪”这件事直接决定了中断能不能被正确响应。对于从0x00000000开始的芯片Flash基址通常会被映射到0x00000000所以不需要额外操作。但IAP的场景是Boot在0x08000000APP在0x08000000 OffsetAPP的向量表并不在CPU默认查找的0x00000000位置。如果不做重映射中断发生时就只能取到Boot的向量或者取到一个无效地址直接HardFault。2.2 三种重映射机制VTOR、存储映射和启动配置业界常见的重映射手段有三类很多工程师只知其一导致在换平台时踩坑。第一类是VTOR寄存器。Cortex-M3/M4/M0内核大多提供了SCB-VTORSystem Control Block Vector Table Offset Register用于告诉CPU“向量表基地址不在0x00000000而是从这个地址开始”。这是最直接的方式代码里一行SCB-VTOR APP_BASE;就能解决问题。但要命的是不是所有芯片都允许你随意写这个寄存器也不是写了就一定会立即生效。这取决于内核版本、总线映射和芯片厂商的具体实现。第二类是存储器映射寄存器。部分MCU支持把不同的存储区映射到0x00000000通过修改映射寄存器让CPU上电后直接从APP所在的Flash区取向量。典型如部分国产MCU的“存储映射切换”功能。这一类操作往往比VTOR更底层如果只改VTOR不改映射仍然可能死机。第三类是启动配置/Option Bytes。通过烧录Option Bytes或者配置Boot引脚让芯片在复位后先从指定的存储区启动。这种方式一般用于产线烧录配合IAP动态切换比较少见但有些双Bank升级方案会依赖它。很多工程师把“重映射”等同于“写VTOR”这个认知在单个平台上可能够用一旦换到GD32、HC32或者从F1换到F4就会出问题。准确地说重映射的本质是保证“中断发生时CPU能找到APP区的向量表”至于具体靠哪个寄存器必须查芯片手册的Memory Mapping章节。2.3 对齐、初始化顺序与“写成功但没生效”VTOR不是随便给个地址就能用的它有两个隐含约束约束一对齐要求。Cortex-M3/M4要求向量表基地址对齐到至少0x80字节实际工程中普遍按0x200或0x100对齐。M0内核则要求字对齐4字节但保险起见建议按向量表总大小的整形数倍对齐。如果你把APP放在0x0800F800这种非对齐地址写VTOR时低位会被硬件忽略实际上指到了别的地址。约束二初始化顺序。向量表里装的是绝对地址而不是相对于当前PC的偏移。所以只要代码段在Flash里向量表本身并不需要“搬运”只需要让VTOR指向它。但如果你搞的是RAM向量表方案就必须在中断使能之前把Flash里的向量表内容拷贝到RAM里并且完成VTOR切换否则一个中断进来就会抓狂。我还见过一种“写成功但没生效”的情况某些内核在VTOR写入后需要有屏障操作比如__DSB()、__ISB()否则紧随其后的中断可能依然走旧向量表。这个问题在M0上尤其容易被忽略。所以一个规范的VTOR切换流程至少应该包含SCB-VTOR (uint32_t)app_vector_table; // 设置偏移 __DSB(); // 数据同步屏障 __ISB(); // 指令同步屏障不要觉得这两行是多余少了它们很多“偶发死机”就是这么来的。3. 让升级死机的四个“绝对禁忌”3.1 禁忌一跳转前不清理外设和NVIC状态Boot里通常要初始化UART、Flash、定时器甚至开启一些中断来完成升级通信。很多人的跳转代码只写了三行关全局中断、设置MSP、跳转。问题恰恰出在这。跳进APP之后如果Boot里某个外设中断正处于Pending状态又或者NVIC的对应使能位还是1那么APP在初始化外设的过程中可能刚打开一个中断之前挂起的中断就立刻进来。此时VTOR还没被APP设置好CPU只能去旧向量表找入口直接跑飞。正确的做法是在跳转前做几件“脏活”关闭所有外设、清掉NVIC里所有Pending位、把所有已使能的中断位清空、SysTick也一并关掉。我习惯在跳转函数里直接暴力刷一遍NVICSysTick-CTRL 0; for (uint32_t i 0; i 8; i) { NVIC-ICER[i] 0xFFFFFFFF; // 关闭所有中断 NVIC-ICPR[i] 0xFFFFFFFF; // 清掉所有Pending位 }不要觉得暴力IAP跳转本来就是系统级行为宁可牺牲一点性能也要保证状态干净。3.2 禁忌二链接地址与VTOR偏移各说各话这是我在各类IAP帖子下看到最多的问题。典型写法是这样的#define APP_BASE 0x08010000 SCB-VTOR APP_BASE;但打开Keil的Target页面一看IROM1还是从0x08000000开始或者链接脚本里的首地址没改。这时候APP的Reset_Handler实际链接在0x08000000开始的区域APP的代码却以为自己从0x08010000开始。两套地址错位结果是Boot从APP头部读出来的MSP和Reset可能是对的但跳进去之后所有全局变量的地址都对不上中断向量表也根本不在0x08010000。正确做法是让“链接地址”、“VTOR数值”、“Flash烧录地址”三者保持一致。以Keil为例IROM1的Start地址要改成0x08010000Size要改成0x00070000然后代码里VTOR也用0x08010000。用GCC的话就是链接脚本里的FLASH (rx) : ORIGIN 0x08010000。验证方法很简单编译后打开map文件看__initial_sp的地址和Reset_Handler的地址。如果Reset_Handler落在0x08010000附近说明链接没问题如果还在0x08000000附近那链接配置就没生效。3.3 禁忌三RAM向量表搬运和对齐没做好有些场景会刻意把向量表放到RAM里典型就是需要频繁更新APP、或者Boot本身运行在RAM里的方案。思路是在RAM里开一块区域把APP开头的一段向量表拷贝过去再把VTOR指向RAM里的新表。这里有三个坑坑一拷贝时机太晚。如果拷贝动作放在APP的main函数里做而系统在main之前就已经把外设中断打开了那中断随时可能踩到还没准备好的向量表。坑二对齐不对。我见过有人把__attribute__((aligned(4)))当成万能对齐但在M3上RAM向量表地址至少要对齐到0x200。如果你的app_vector_table只对齐了4字节VTOR写入后低位被截断指向了错误的RAM地址。坑三数组大小不够。有些芯片的外设中断号很多向量表远不止128字节。拷贝长度如果只按自己用到的中断数去截取后面未拷贝的区域就是RAM里的随机值中断一旦发生PC直接跳飞。一个稳妥的RAM向量表初始化长这样#define APP_BASE 0x08010000 #define VECTOR_TABLE_SIZE 256 // 按芯片实际中断数放大 uint32_t ram_vector_table[VECTOR_TABLE_SIZE] __attribute__((aligned(0x200))); void relocate_vector_table_to_ram(void) { memcpy(ram_vector_table, (uint32_t *)APP_BASE, VECTOR_TABLE_SIZE * 4); SCB-VTOR (uint32_t)ram_vector_table; __DSB(); __ISB(); }这段函数必须在任何外设中断使能之前调用最好放在启动文件进入C代码后的第一行。3.4 禁忌四APP中断函数根本不在APP区很多人以为只要VTOR指到了APP区中断路径就没问题了。不对。VTOR负责找到“向量表”向量表里的中断函数地址必须真正落在APP的代码段里。如果中断函数的实现还在Boot区或者根本没有被编译进APP段那结果还是一样死机。这种问题在“AB区共用源码”的工程里尤其多见。比如Boot和APP是同一个工程用宏区分构建中断服务函数只写在Boot段里APP段因为某种条件编译把这部分代码排除了。此时APP里的中断向量表虽然存在但表里的地址指向的是一个不存在于APP段的函数跳过去就是未定义行为。另外还有一种隐蔽情况使用了弱定义的默认中断处理函数。Cortex-M的启动文件里通常会为每个中断定义一个weak类型的死循环或HardFault入口如果APP里漏写了某外设的中断服务函数链接器可能把它解析到启动文件的默认入口这个入口不一定在APP段也可能被放到了Boot那边。解决方案是在APP启动文件里给所有中断都生成一份实体定义哪怕内容是空函数也要让链接器确定地址属于APP区。3.5 追加一个高频困惑Boot区变量复位后的生命周期有人问“iap boot里面定义的变量复位后会怎样”这个问题问得非常好因为它直接触碰到了IAP方案里一个容易被忽略的边界。Boot里定义的普通全局变量按C规则是放在RW段或ZI段里的。这些变量只在Boot启动代码执行时被初始化。Boot跳转进APP之后这些变量在内存里其实还占着位置但APP一般不知道它们的存在。如果APP刚好把这块RAM地址用作自己的变量或堆栈那么Boot写入的标志位、升级状态、甚至跳转参数可能在APP启动过程中就被覆盖清零。更麻烦的是“复位”场景如果设备在升级过程中意外复位CPU重新从Boot执行Boot的启动代码会把它的RW段初始化一遍把全局变量恢复成默认值。此时如果你在Boot的main函数里靠一个“上次升级未完成”标志来判断要不要继续升级这个标志已经被清零了逻辑就断了。所以跨Boot/APP传递数据时不要依赖普通全局变量应该使用专门的保留RAM区域或备份寄存器。比如#define BOOT_FLAG_ADDR 0x2000F000 // 链接脚本里把这块地址标记为NOINIT volatile uint32_t *boot_flag (volatile uint32_t *)BOOT_FLAG_ADDR;然后确保APP和Boot的链接脚本都把这段RAM排除在堆栈和RW段之外谁也不碰它。这才是真正可靠的双区通信方式。4. GD32F103、HC32L136、STM32F103三平台对照实测4.1 GD32F103Cortex-M3常规玩法GD32F103是Cortex-M3内核IAP跳转方式与ST同内核产品很接近。在GD32的官方例程里通常也是跳转前设置SCB-VTOR然后跳转到APP的Reset_Handler。实测下来直接写VTOR是有效的但需要和链接地址严格一致。我这边的一个稳定写法是#define GD32_APP_BASE 0x08008000 typedef void (*app_entry_t)(void); void gd32_jump_to_app(void) { uint32_t msp *(volatile uint32_t *)GD32_APP_BASE; uint32_t reset *(volatile uint32_t *)(GD32_APP_BASE 4); __disable_irq(); SysTick-CTRL 0; for (uint32_t i 0; i 8; i) { NVIC-ICER[i] 0xFFFFFFFF; NVIC-ICPR[i] 0xFFFFFFFF; } SCB-VTOR GD32_APP_BASE; // 重映射中断向量表 __DSB(); __ISB(); __set_MSP(msp); ((app_entry_t)reset)(); }有几个细节需要说明。GD32F103虽然和STM32F103同为Cortex-M3但个别型号在VTOR的写保护、Flash等待周期设计上有差异。如果你发现写了VTOR后仍然死机优先确认三件事APP链接地址是否等于GD32_APP_BASE、Flash擦写时有没有关闭中断、跳转地址处是否真的有正确的MSP和Reset值。另外GD32的Flash擦写时序比ST常见型号更敏感升级过程中如果看门狗没喂或者中断长时间关闭可能会导致Flash状态机出错。这块建议在Boot里单独做看门狗处理和擦写失败重试不要和跳转逻辑纠缠在一起。4.2 HC32L136M0内核下的差异点HC32L136是Cortex-M0内核它的向量重映射特性跟M3有不少区别。Cortex-M0也有VTOR寄存器但它没有M3那么完备的异常系统对齐要求也更宽松字对齐。在实际项目里HC32L136的IAP死机往往不是出在VTOR本身而是出在系统存储器映射上。这家MCU的地址映射和ST/GD的经典布局不太一样Flash、RAM、外围寄存器各有映射位。如果你在HC32上只改了VTOR没有把系统映射寄存器切到APP所在Flash区上电后CPU从0x00000000取到的可能依然是Boot区内容中断向量自然也是错的。具体的寄存器名和位定义要查HC32L136用户手册的“Memory Mapping”章节不同批次甚至可能有差异。我在这颗芯片上踩过的坑是仿真器里一切正常脱机必死。原因是仿真器初始化时把映射寄存器设置成了预期值而冷启动时映射寄存器的复位值是默认状态Boot代码里又没有显式配置。后来我在Boot启动最前面加上映射配置问题才消失。给HC32平台的建议是不要只抄ST的跳转模板先花半小时把手册里的Memory Mapping、启动配置、Option字节通读一遍确认你用的工程模板是不是“可以用调试器掩盖真相”的那种——很多厂商的示例工程为了方便开发默认做了很多“牺牲”。4.3 STM32F103/F4对照别拿F4经验套F1STM32F103也是Cortex-M3它的IAP重映射手段比较经典但有个历史细节让很多人困惑F1系列的VTOR写操作在部分资料里被标注为“不可用”或者“只能写到RAM区域”导致很多从F4转到F1的工程师抄作业失败。实际上我在STM32F103上实测直接写SCB-VTOR是可行的但前提是系统存储器映射处于常规Flash启动状态。STM32F1的地址0x00000000只是Flash的别名映射区并不像F2/F4那样有独立的SYSCFG内存重映射控制位。因此在F1上你只需要保证VTOR指向0x08000000 偏移一般就能工作。而STM32F4系列因为有了SYSCFG_MEMRMP很多工程师会额外配置一个“内存重映射”用来在系统Bootloader和主Flash之间切换。如果你把F4的这套做法原封不动搬到F1反而可能在F1上访问到不存在的寄存器触发HardFault。平台内核重映射方式实测注意点GD32F103Cortex-M3SCB-VTOR Flash偏移与链接地址严格一致Flash擦写时序敏感HC32L136Cortex-M0SCB-VTOR 系统存储器映射必须核对冷启动时的映射寄存器复位值STM32F103Cortex-M3SCB-VTOR常规Flash启动下可用不要抄F4的SYSCFG流程STM32F4Cortex-M4SCB-VTOR对齐按0x100或向量表大小SYSCFG用于bank切换这张表是我在最近几个项目里的实测记录不代表所有批次和所有SDK版本都如此。换平台后第一件事永远是查手册而不是复制代码。4.4 一份可复制的跳转封装函数综合上面的经验我整理了一个相对通用的跳转函数可以按你当前平台微调后直接用typedef void (*app_entry_t)(void); static void jump_to_app(uint32_t app_base) { uint32_t msp *(volatile uint32_t *)app_base; uint32_t reset *(volatile uint32_t *)(app_base 4); __disable_irq(); SysTick-CTRL 0; for (uint32_t i 0; i 8; i) { NVIC-ICER[i] 0xFFFFFFFF; NVIC-ICPR[i] 0xFFFFFFFF; } /* 根据平台决定是否需要额外配置存储器映射寄存器 */ SCB-VTOR app_base ~0x1FFU; // 512B对齐按需调整 __DSB(); __ISB(); __set_MSP(msp); ((app_entry_t)reset)(); }调用前建议把app_base打印或写到调试变量里确认它是不是你预期的APP基址。这里最容易被忽视的是app_base低9位对齐问题如果基址不是512的整数倍硬件会忽略低位等于VTOR设置到了别处。5. 一次死机定位的完整排查链路而不是直接告诉你答案5.1 第一步拔掉调试器保持冷启动复现我收到故障报告后的第一个操作永远是让现场人员把调试器断开设备断电再上电。如果在仿真器连接状态下做这个测试几乎没有任何意义因为调试器可能已经改变了内核状态。拿到一台必现死机的设备后先别急着看代码用串口打印复现。Boot阶段打印Boot Start跳转前打印Jump to AppAPP的main第一行打印App Init。如果串口停在Jump to App说明跳转动作本身没执行完如果打印了App Init但后续中断相关输出没有基本就是中断向量表的问题。这种分层打印是定位IAP问题最朴素但最有效的手段。你不需要昂贵的逻辑分析仪也不需要JTAG tracer一条串口线就能把问题范围砍掉一半。5.2 第二步打开map文件与反汇编人工验证向量表串口打印定位到“进APP但中断无效”之后我再做一次静态验证。打开APP编译生成的map文件确认两个关键符号__initial_sp的地址应该在APP基址附近。Reset_Handler的地址应该在APP段内。然后打开反汇编文件找到app_base地址处的前8字节确认这里的值是不是“一个合法的RAM地址 一个合法的Flash函数地址”。比如APP基址是0x08010000那么地址0x08010000处应该存MSP初值比如0x2000xxxx地址0x08010004处应该存Reset_Handler地址比如0x08010019。如果看到的是0xFFFFFFFF或者0x08000000附近的值说明烧录时APP的向量表就没放对位置或者链接脚本把启动段排到别的地址去了。这一步完全不需要开发板用fromelf或objdump就能看。这也是我强烈建议每个嵌入式工程师掌握的基础技能不要只依赖IDE里点击Run的绿色按钮要会读二进制布局。5.3 第三步加打印桩分离“死在哪一步”静态验证通过之后如果问题还复现那就要怀疑动态过程了。我会在跳转函数的关键节点加打印桩printf(before disable irq\r\n); __disable_irq(); printf(after disable irq, vtor%x\r\n, (unsigned int)SCB-VTOR); SCB-VTOR app_base; printf(after set vtor, vtor%x\r\n, (unsigned int)SCB-VTOR);这个打印很重要。有些芯片的VTOR写入后读回来的值和你写的值不一样这时候就能直接看到硬件是否接受了你的VTOR设置。我在HC32L136上就遇到过寄存器读回来的数值表明写操作被“忽略”了后来发现是因为总线映射位没配对。还有一个小技巧跳转前在RAM里放一个魔数比如0xA5A5A5A5APP启动第一件事检查这个魔数。如果魔数还在说明跳转后RAM数据没被破坏Boot和APP的内存区域没有互相踩踏如果魔数丢了说明APP的启动代码把Boot留下的RAM区域覆盖了这就是数据传递和RAM布局冲突的证据。5.4 关于“偶发死机”的复现方法论偶发死机比必现死机更考验工程方法。我的做法是先把条件变量缩小。比如把升级流程拆成“下载固件”、“擦除Flash”、“写入Flash”、“校验”、“跳转”五段分别在每段结束后打一个时间戳。然后调整供电方式、干扰源、通信波特率等条件看死机是否跟着某个条件变化。如果偶发死机和“热拔插”“快速断电重启”强相关重点排查外设状态残留和掉电时序。如果偶发死机和“升级包内容”强相关重点排查Flash写入是否完整、附件区有没有数据覆盖。这里不要靠肉眼盯串口建议直接写个PC端脚本自动记录串口日志跑几百轮之后统计死机位置分布比人工反复按复位键高效得多。以我的经验IAP偶发死机里约有一半是NVIC残留导致的中断风暴另一半是RAM冲突。这两种问题在偶发时都非常难看但只要打印桩和复现脚本到位往往半天就能锁定根因。6. 移植前可以抄作业的最终自查清单6.1 工程配置层面在动一行代码之前先把下面这几项确认清楚。这些检查项是我每次做IAP移植前都会过一遍的清单能挡掉大部分低级死机。检查项具体要求Boot和APP的Flash区不重叠Boot区结束地址必须小于APP区起始地址APP链接起始地址与SCB-VTOR设置值完全一致对齐约束VTOR地址满足平台要求M3/M4建议512BM0至少字对齐Boot的RAM区与APP的RAM区互不重叠尤其是堆栈和全局变量区域中断向量表大小按芯片最大中断号规划不止按自己用到的那几个有些工程喜欢把Boot做得很少只在开头留4KB结果APP也从4KB之后开始两段几乎贴在一起。这种布局不是不行但每次改动Boot或APP的编译选项都要重新确认边界条件否则随时可能越界互踩。建议Boot至少留出一个扇区的余量别把空间卡得太死。6.2 代码运行层面工程配置确认完再检查运行逻辑。我归纳了五个关键词关闭、清空、对齐、屏障、顺序。跳转前是否关闭了全局中断、SysTick、外设中断是否清空了NVIC的所有Pending位RAM向量表方案是否完成了对齐和拷贝写VTOR之后是否加了__DSB()和__ISB()APP里对VTOR的修改是否发生在任何中断使能之前这五件事任何一个出问题都可能在外面表现成“升级死机”。而且它们之间会互相叠加关闭中断做不彻底偶尔跑一次没问题外设多、中断频率高的时候才暴露特别难查。6.3 生产与容错层面最后一个层面是生产环境。我在很多客户现场见过这种情况功能样机升级一百次都没事一到产线批量烧录就偶尔死几台。这种差异往往不是代码逻辑突然变了而是产线环境的供电质量、烧录器稳定性、操作人员断电时机都不如实验室可控。对应的设计思路有两个第一升级流程必须可重入。升级到一半断电重新上电后应该能自动回到Boot并重新进入升级模式而不是让设备卡死在半成品状态。升级完成标志要写到Flash或备份寄存器里切不可只放在RAM里。第二跳转之前做一次完整性校验。对APP区域的CRC32或者简单的累加和校验校验不过就不跳转。这不只是防止升级包损坏同时也是防止“擦除成功但写入不完整”的情况。很多“升级后死机”其实根本不是向量表问题而是APP区域里有段数据是错的跳进去之前就已经注定会死。我现在的习惯是任何IAP功能合入主线之前先拿一批开发板做400次连续冷启动升级测试所有板子全部脱机运行日志自动判读。这个流程看起来很笨但确实帮我挡住了好几类只看仿真器根本发现不了的问题。中断向量表重映射的bug往往不是你一眼能看穿的而是藏在你最信任的“能跑通”背后等到量产现场才给你惊喜。