NXP KW38蓝牙OTAP实战：从内存布局到固件升级全解析

1. 项目概述

在物联网设备开发中，固件更新一直是个让人头疼的问题。想象一下，成千上万的传感器节点部署在工厂车间、楼宇角落或者野外环境中，当需要修复一个关键漏洞或增加新功能时，难道要派人一个个去拆机、接线、刷写吗？这显然不现实。空中升级（Over-The-Air Programming， OTAP）技术就是为了解决这个痛点而生的。它让设备能够通过无线通信，安全、可靠地接收并安装新固件，彻底摆脱了线缆的束缚。

我最近在基于NXP KW38蓝牙微控制器开发一个温度采集器项目时，就遇到了这个需求。KW38本身集成了蓝牙5.0低功耗（Bluetooth LE）控制器，非常适合作为低功耗物联网节点的核心。NXP为其提供了OTAP客户端服务的软件框架，但官方文档更像是一份“操作手册”，告诉你一步步怎么做，却很少深入解释“为什么这么做”以及“踩坑了怎么办”。在实际集成过程中，我遇到了从内存布局冲突到服务属性配置的一系列问题。本文将基于我的实战经验，不仅复现集成步骤，更会深入剖析OTAP在KW38上的工作原理、内存管理机制，并分享那些在官方指南里找不到的调试技巧和避坑指南。无论你是刚开始接触KW38，还是正在为现有项目添加OTA功能，相信这些内容都能帮你少走弯路。

2. OTAP核心机制与KW38内存架构深度解析

在动手写代码之前，我们必须先吃透OTAP在KW38上是如何工作的。这不仅仅是调用几个API那么简单，它涉及到芯片存储资源的精细划分、引导流程的巧妙设计以及无线通信的可靠保障。理解这些底层机制，是后续一切调试和优化的基础。

2.1 KW38的存储空间布局与角色分配

KW38的存储资源并不算特别充裕，因此需要精打细算。其片上存储主要分为两部分：

1. 主闪存（P-Flash）：容量为256KB，地址范围是0x0000_0000到0x0003_FFFF。这是程序运行的“主战场”，我们编写的应用程序代码就存放在这里。它被划分为多个2KB的扇区，这是擦除和编程的最小单位。
2. FlexNVM：同样为256KB，地址范围是0x1000_0000到0x1003_FFFF。这块存储区域比较特殊，它可以通过别名地址（0x0004_0000到0x0007_FFFF）进行访问。在OTAP的语境下，FlexNVM常被用作固件镜像的临时缓存区。

OTAP方案的核心思想是“双映像”和“角色分离”。整个Flash空间在逻辑上被划分为两个独立的部分，分别存放两套不同的软件：

• OTAP引导加载程序（Bootloader）：这是一段非常精简、可靠的代码，通常固定存放在P-Flash最开始的8KB空间（0x0000_0000-0x0000_1FFF）。它的职责单一而关键：上电或复位后，检查是否有新的固件镜像等待升级。如果有，则负责将新镜像从缓存区（FlexNVM或外部Flash）搬运到主程序区，并跳转执行。
• OTAP客户端应用程序：这是我们开发的主应用程序，它包含了业务逻辑（如温度采集）和关键的OTAP蓝牙服务。它被链接到P-Flash中Bootloader之后的空间，例如从0x0000_2000开始。这意味着我们的应用程序编译时，必须指定一个8KB的偏移量，为Bootloader预留空间。

这种设计形成了一个安全的更新链条：设备出厂时，首先烧录Bootloader，然后烧录支持OTAP的V1.0应用程序。当V2.0固件通过蓝牙传来时，应用程序（作为OTAP客户端）负责接收并暂存。接收完成后，它设置一个标志并重启。Bootloader看到标志后，执行更新操作，用V2.0覆盖原来的V1.0应用程序区域。如果V2.0也集成了OTAP服务，那么设备在未来就能继续升级到V3.0，实现可持续的无线更新能力。

注意：这里有一个至关重要的细节。Bootloader和应用程序的边界（8KB）是由链接脚本（Linker Script）硬性定义的。如果你修改了Bootloader的大小，或者应用程序的起始地址，必须同步更新链接脚本和应用程序的编译偏移量，否则会导致程序无法正常启动或升级失败。在实际项目中，我曾因为忽略了这一点，导致升级后程序跑飞，最后只能通过J-Link重新烧录救砖。

2.2 固件传输与存储策略选择

蓝牙LE的通信特性决定了它不适合一次性传输整个固件镜像（可能几百KB）。因此，OTAP采用“分块传输”的策略。服务器端将完整的固件镜像（通常是S-Record或Hex格式）切割成多个小块，称为“数据块”（Chunk），通过蓝牙ATT协议逐个发送给客户端。

KW38的OTAP客户端提供了两种存储这些数据块的方案，你需要根据硬件设计和需求进行选择：

1. 外部SPI Flash存储：FRDM-KW38开发板上预置了一颗AT45DB041E SPI Flash芯片。这是官方默认且推荐的方式。优点在于容量大（512KB），不占用宝贵的片上资源，并且读写速度相对较快。如果你的产品板载了类似的外部存储，这是首选。
2. 片上FlexNVM存储：将接收到的数据块直接写入KW38片内的FlexNVM区域。这种方式无需外部元件，成本更低。但缺点是FlexNVM容量有限（256KB），且需要与应用程序共享这块资源。如果你的固件体积较小，且产品对成本极其敏感，可以考虑此方案。

选择哪种方案，需要在项目早期的app_preinclude.h文件中通过gEepromType_d宏定义来指定。这个选择会影响底层驱动（如SPI初始化）的编译，以及Bootloader在更新时寻找源镜像的位置。

2.3 引导加载程序与标志位通信机制

Bootloader和应用程序是两个独立的程序，它们之间如何通信呢？答案是通过一块约定的内存区域——Bootloader标志区。这通常是在Flash中预留的几个特定字节。

当OTAP客户端应用程序完成新固件镜像的接收和校验后，它会执行以下关键操作：

1. 将新镜像的存储位置（是外部Flash还是FlexNVM）、镜像大小、CRC校验值等信息写入Bootloader标志区。
2. 主动触发一次MCU的软复位。

MCU复位后，首先运行的永远是Bootloader。Bootloader的初始化代码会第一时间去检查Bootloader标志区。如果发现有效的升级标志，它就根据标志区记录的信息，找到新镜像的存放地址，然后执行擦除、编程等操作，将新固件写入应用程序区。全部完成后，清除标志，并跳转到新的应用程序入口地址开始执行。

这个机制看似简单，却极其健壮。即使升级过程因断电中断，Bootloader下次启动时依然能看到未完成的标志，可以尝试继续或回滚（取决于设计），避免了设备“变砖”的风险。

3. 开发环境搭建与基础工程准备

工欲善其事，必先利其器。在开始集成OTAP服务之前，一个干净、可靠的开发环境是成功的基石。本节将详细说明如何搭建基于MCUXpresso IDE的环境，并准备好我们的“改造”对象——基础的温度采集器（Temp Coll）工程。

3.1 软件工具链的获取与安装

NXP为KW38提供了完整的软件开发套件（SDK）和集成开发环境（MCUXpresso IDE），我们需要按顺序获取它们。

第一步：获取MCUXpresso IDE访问NXP官网，下载并安装最新版本的MCUXpresso IDE。这是一个基于Eclipse的免费开发环境，对NXP MCU系列支持良好。安装过程比较简单，注意选择合适的安装路径即可。

第二步：定制并下载KW38 SDK这是至关重要的一步。SDK包含了芯片的所有底层驱动、蓝牙协议栈、以及丰富的示例代码。

1. 打开MCUXpresso IDE，进入其“MCUXpresso SDK Builder”视图。
2. 在开发板搜索框中输入“FRDM-KW38”并选择。
3. 在配置页面，工具链选择“GCC”，这是我们将使用的编译器。然后，务必勾选“Bluetooth”相关的所有组件，特别是“Bluetooth Host Stack”和“Bluetooth Examples”。OTAP服务依赖于完整的蓝牙主机协议栈。
4. 点击“下载SDK”，系统会生成一个包含所有选定组件的ZIP包。下载完成后，直接将这个ZIP文件拖拽到MCUXpresso IDE的“Installed SDKs”窗口中，IDE会自动解压并配置好路径。

第三步：导入基础示例工程我们选择“Temperature Collector”作为基础工程。这是一个经典的蓝牙中央设备（Central）示例，它主动扫描并连接周围广播温度数据的传感器外设（Peripheral）。在IDE中，通过“File -> New -> Project from Example…”导航，选择已安装的FRDM-KW38 SDK，找到“temp_collector”工程并导入。编译并下载到开发板，确保基础功能正常：按下按键开始扫描，LED灯状态变化，串口有日志输出。这个可工作的工程将是我们集成OTAP的起点。

3.2 理解工程结构与关键文件

在动手修改之前，花点时间熟悉一下SDK工程的结构，能让你在后续集成时心中有数。一个典型的KW38蓝牙工程包含以下关键目录和文件：

• source/：应用层源代码所在。我们的主逻辑文件temperature_collector.c就在这里。
• bluetooth/：蓝牙协议栈、配置文件（Profiles）和服务（Services）的源代码。我们将要集成的OTAP、电池、设备信息服务都在这里的profiles/子目录下。
• framework/：包含芯片外设驱动、Flash操作、串口管理、OTA支持等中间件框架。OtaSupport和Flash/External目录对OTAP至关重要。
• board/：板级支持包，包含引脚初始化（pin_mux.c/.h）、硬件抽象层函数。
• linkscripts/：链接脚本目录。文件main_text_section.ldt决定了代码和数据在内存中的布局，是OTAP偏移量配置的关键。
• app_preinclude.h：全局预编译头文件，用于集中定义功能宏、配置参数，如是否启用低功耗、蓝牙安全模式、以及我们即将要配置的OTAP存储类型。
• gatt_db.h和gatt_uuid128.h：这两个文件定义了设备的GATT（通用属性配置文件）数据库。简单说，它规定了你的蓝牙设备“提供什么服务”、“每个服务有哪些特征（数据点）”、“这些特征是否可读可写”。OTAP服务就是以一系列特定UUID（通用唯一标识符）的特征形式存在的。

4. OTAP服务集成实战：从文件对接到代码融合

现在进入核心环节：将OTAP客户端服务“缝合”到我们的温度采集器工程中。这个过程就像做外科手术，需要仔细比对、精准移植。我将以“温度采集器（Temp Coll）”工程为例，展示完整的集成步骤。

4.1 文件与目录结构的比对与移植

首先，我们需要知道OTAP客户端工程比我们的基础工程多了哪些“零件”。最直接的方法是在MCUXpresso IDE中同时打开“OTAP Client”示例工程和我们的“Temp Coll”工程，进行目录结构对比。

关键缺失目录与文件清单：通过对比，我发现需要在Temp Coll工程中创建并补全以下目录和文件：

1. 蓝牙配置文件层：
   • bluetooth/profiles/battery/：电池服务接口文件（battery_interface.h/c）。OTAP过程可能耗时较长，向用户报告设备电量是个好习惯。
   • bluetooth/profiles/device_info/：设备信息服务（device_info_interface.h,device_info_service.c）。用于提供设备名称、厂商、固件版本等信息，便于服务器识别。
   • bluetooth/profiles/otap/：OTAP服务核心文件（otap_interface.h,otap_service.c）。定义了OTAP服务的GATT属性及处理逻辑。
2. 框架支持层：
   • framework/Flash/External/：外部Flash（如SPI Flash）的驱动接口和源码。如果选择外部存储，必须包含。
   • framework/OtaSupport/：OTA支持模块，提供镜像校验、状态管理等通用函数。
   • framework/SerialManager/source/SPI_Adapter/：SPI串行管理器适配器，用于驱动外部SPI Flash。
3. 应用与链接层：
   • source/common/otap_client/：OTAP客户端应用层逻辑（otap_client.h/c），负责协调OTAP服务、存储驱动和Bootloader标志的写入。
   • linkscripts/main_text_section.ldt：关键文件！OTAP客户端工程的链接脚本已经包含了8KB的偏移量配置，必须用它替换掉原来的。

操作步骤：

1. 在Temp Coll工程中，右键点击相应父目录，选择“New -> Folder”，逐一创建上述缺失的文件夹。
2. 从OTAP Client示例工程中，找到上述列表中的所有文件，直接复制（Ctrl+C）并粘贴（Ctrl+V）到Temp Coll工程对应的新建文件夹中。
3. 库文件替换：在工程的libs/文件夹下，你会发现一个名为lib_ble_5-0_host_central_cm0p_gcc.a的库文件。这是基础蓝牙主机库。OTAP需要功能更全的库。从SDK路径<你的SDK路径>/middleware/wireless/bluetooth/host/lib/下找到lib_ble_5-0_host_cm0p_gcc.a，将其拖入工程并删除旧库。

4.2 工程配置与路径设置

文件复制过来后，编译器还需要知道去哪里找它们。

1. 添加头文件包含路径：

   • 右键工程 -> “Properties”。
   • 导航到 “C/C++ Build -> Settings -> Tool Settings -> MCU C Compiler -> Includes”。
   • 点击“Include paths”旁的添加按钮，然后点击“Workspace”，将我们刚刚创建的所有包含头文件的目录添加进去。主要是各个Interface目录和otap_client目录。确保路径正确无误。

2. 更新链接器库路径：

   • 在同一属性页，导航到 “MCU Linker -> Libraries”。
   • 在“Libraries”列表中，将旧的_ble_5-0_host_central_cm0p_gcc移除，添加新的_ble_5-0_host_cm0p_gcc。
   • 在“Library search path”中，确保路径指向正确的库文件位置。

完成以上步骤后，尝试编译工程。此时大概率会报错，因为源文件还没有进行代码集成。但这一步确保了所有必要的“原材料”都已就位。

4.3 关键源代码文件的修改详解

这是集成工作中最需要耐心和细心的部分。我们需要深入修改主应用文件，将OTAP服务的逻辑“编织”到原有的应用流程中。

4.3.1 硬件引脚与基础配置 (pin_mux.c,app_preinclude.h)

• pin_mux.c：如果选择外部SPI Flash作为存储，需要初始化SPI引脚。在BOARD_InitPins()函数中或单独的函数里，添加SPI相关引脚的复用配置（例如，将PORTC的16-19引脚配置为SP0功能）。代码可以直接从OTAP示例中复制BOARD_InitSPI()函数。
• app_preinclude.h：这是配置的“总开关”。

  /* 1. 定义存储类型：AT45DB041E外部Flash 或 FlexNVM */ #define gEepromType_d gEepromDevice_AT45DB041E_c // 使用外部Flash // #define gEepromType_d gEepromDevice_FlexNVM_c // 使用片内FlexNVM /* 2. Bootloader标志写入对齐参数，通常保持默认 */ #define gEepromParams_WriteAlignment_c 8 /* 3. 启用OTAP客户端ATT传输 */ #define gOtapClientAtt_d 1

  这里的选择决定了后续驱动编译和运行时行为。

4.3.2 蓝牙广播与GATT数据库 (app_config.c,gatt_db.h)

• app_config.c：

  1. 修改广播数据：我们需要在广播包中声明设备支持OTAP服务，这样OTAP服务器（如手机App）才能扫描并识别它。找到gAppAdvertisingData相关的结构体，在128位服务UUID列表（adData1数组）中，加入OTAP服务的UUID。这个UUID可以在OTAP示例工程的gatt_uuid128.h中找到，通常是0xE0, 0x1C, ...这一长串数字。同时，可以修改设备广播名，例如改为 “NXP_OTAP_Temp”。
  2. 添加服务安全要求：在serviceSecurity数组中，为OTAP服务添加一项安全配置，例如要求加密连接（gSecurityMode_1_Level_3_c）。同时，将deviceSecurityRequirements结构体中的服务数量cNumServices从原来的1（可能只有温度服务）增加到3（温度、电池、OTAP）。

• gatt_db.h与gatt_uuid128.h：

  • 这是最易出错的地方。你需要将OTAP示例中gatt_db.h里关于OTAP服务的所有属性定义（一大串ATT_DECL_*宏）完整地复制到你的工程的gatt_db.h中。这定义了OTAP服务的特征，如“升级控制点”、“升级状态”、“升级数据”等。
  • 同样，将gatt_uuid128.h中OTAP服务及其特征的UUID定义复制过来。UUID是蓝牙服务全球唯一的标识符，必须完全匹配。

4.3.3 主应用逻辑集成 (temperature_collector.c)

这是修改量最大的文件，需要让应用在“温度采集器”和“OTAP客户端”两个角色间切换。

1. 包含头文件与全局变量：

   • 在文件开头，添加OTAP、电池、设备信息服务的头文件#include。
   • 声明OTAP相关的全局变量和函数原型，例如static gapRole_t mGapRole;用于记录当前设备角色（中央设备还是外设）。

2. 修改BleApp_Start函数：

   • 原函数可能只处理扫描（中央设备行为）。需要根据mGapRole变量的值进行分支：如果是中央设备角色，则启动扫描；如果是外设角色，则启动广播。这使设备能通过按键在两种模式间切换。

3. 修改BleApp_HandleKeys函数：

   • 为按键（例如SW2）添加处理逻辑，用于切换mGapRole。按下一次，从“温度采集器”模式切换到“OTAP服务器”模式（开始广播OTAP服务）；再按一次，切换回来。

4. 增强BleApp_Config函数：

   • 在初始化部分，调用OtapClient_Config()来初始化OTAP客户端模块。
   • 调用Dis_Start()初始化设备信息服务。

5. 重构BleApp_ConnectionCallback函数：

   • 这是连接事件处理的核心。需要根据当前角色 (mGapRole) 进行分流。
   • 当角色是外设且连接建立时，除了原有的逻辑，必须调用OtapClient_HandleConnectionEvent()。
   • 当角色是外设且连接断开时，调用OtapClient_HandleDisconnectionEvent()。
   • 在连接成功时，还需要订阅OTAP服务的通知：OtapCS_Subscribe(peerDeviceId)。

6. 实现BleApp_GattServerCallback函数：

   • 这个回调函数处理来自蓝牙客户端（例如手机）的所有GATT请求（读、写、通知等）。
   • 你需要添加case分支，将OTAP相关的事件（如gEvtAttributeWritten_c写特征，gEvtMtuChanged_cMTU协商改变）分发给OTAP服务处理函数，例如OtapClient_AttributeWritten()。这些函数在otap_client.c中已实现，我们只需正确路由事件。

7. 添加电池服务定时器（可选但推荐）：

   • 在BleApp_Config中分配一个定时器mBatteryMeasurementTimerId。
   • 在连接回调中启动这个定时器，定期调用BOARD_GetBatteryLevel()获取电量并更新电池服务特征值。

这个过程就像搭积木，必须确保每一块都放对位置。我的经验是，每完成一个函数的修改，就编译一次，即使有错误，也能快速定位到刚刚修改的区域，避免错误累积后无从下手。

5. 编译、调试与升级测试全流程

代码集成完成后，真正的挑战才刚刚开始。编译通过不代表功能正常，我们需要进行系统的测试来验证OTAP的完整链条是否畅通。

5.1 编译配置与链接脚本调整

1. 链接脚本：确保使用了从OTAP示例工程复制过来的main_text_section.ldt文件。用文本编辑器打开它，检查FLASH区域的起始地址是否为0x2000（即8KB偏移）。这确保了我们的应用程序不会覆盖Bootloader区域。
2. 编译优化：为了便于调试，在开发阶段建议将优化等级设为-O0或-Og，并开启调试信息（-g）。在“Properties -> C/C++ Build -> Settings -> MCU C Compiler -> Optimization”中设置。
3. 首次编译：执行“Clean”然后“Build”。你可能会遇到一些头文件找不到或函数未定义的错误。根据错误信息，回头检查：
   • 头文件包含路径是否添加完整。
   • 源文件中是否漏掉了某个#include。
   • 函数原型声明是否正确。
   • 库文件是否已正确替换。

5.2 双映像烧录与Bootloader准备

一个支持OTAP的设备，需要两个独立的镜像：Bootloader 和 应用程序。

1. 烧录Bootloader：

   • 在SDK的boards/frdmkw38/otap_bootloader目录下可以找到Bootloader工程。将其导入MCUXpresso IDE。
   • 编译并通过调试器（如板载OpenSDA）下载到KW38开发板。这个Bootloader会永久驻留在Flash起始的8KB空间。

2. 烧录集成OTAP的应用程序：

   • 回到我们修改好的Temp Coll-OTAP工程。
   • 关键一步：在工程属性的 “C/C++ Build -> Settings -> MCU Linker -> Managed Linker Script” 下，确保“Linker Script”指向了我们修改过的、带偏移量的main_text_section.ldt。
   • 编译工程，生成.axf或.elf文件。
   • 使用调试器再次下载这个程序。由于链接脚本的偏移量配置，编程器会自动将程序烧录到0x2000开始的地址，不会擦除前面的Bootloader。

实操心得：第一次下载应用程序后，如果程序无法运行，先别慌。用调试器连接板子，查看PC指针是否指向0x2000附近的地址。如果不是，说明链接脚本或下载配置有误。也可以读取Flash内存，确认0x0000地址开始是Bootloader的代码，0x2000地址开始是应用程序的代码。

5.3 使用NXP IoT Toolbox进行端到端测试

NXP提供的IoT Toolbox手机App内置了OTAP Server功能，是极佳的测试工具。

1. 设备模式切换：给板上电。默认情况下，我们的程序启动后处于“温度采集器”模式（中央设备，扫描状态）。按下配置好的模式切换按键（如SW2），此时LED灯闪烁模式应改变，串口日志应打印“Advertising…”表示已切换到外设模式并开始广播OTAP服务。
2. 手机端操作：
   • 打开手机蓝牙和NXP IoT Toolbox App。
   • 进入“OTAP”功能。
   • 点击扫描，应该能看到名为“NXP_OTAP_Temp”的设备。连接它。
   • 连接成功后，App会读取设备的服务信息。你需要准备一个用于升级的S-Record（.srec）镜像文件。这个文件就是你的“新固件”。
     • 如何生成升级镜像：在MCUXpresso IDE中，编译你的应用程序工程后，除了.axf，还会在Debug或Release目录下生成同名的.srec文件。这个文件就是可用的升级镜像。切记，这个用于升级的镜像，其工程也必须配置好8KB的链接偏移！否则升级后会覆盖Bootloader。
3. 执行升级：
   • 在IoT Toolbox App中选择本地的.srec文件。
   • 点击“Upgrade”开始传输。App会将文件分块发送给设备。
   • 观察设备串口日志，你会看到接收进度、校验过程。传输完成后，设备会打印“Update received, resetting…”之类的信息，然后自动重启。
4. 验证升级结果：
   • 设备重启后，Bootloader检测到有效的升级标志，开始执行更新操作（擦写Flash）。这个过程通常很快。
   • 更新完成后，Bootloader跳转到新的应用程序。此时，设备运行的就是你刚刚传输的“新固件”。
   • 验证新固件功能是否正常。如果新固件也集成了OTAP服务，你可以再次按下切换按键，让它广播OTAP服务，进行下一次升级测试，形成闭环。

5.4 常见问题排查与调试技巧实录

在实际集成中，我遇到了不少问题，这里总结出几个最具代表性的：

问题一：编译通过，但下载后设备无反应，或无法切换到OTAP广播模式。

• 排查思路：
  1. 检查链接脚本：这是首要怀疑对象。确认FLASH起始地址是否为0x2000。可以用arm-none-eabi-objdump -h your_project.axf命令查看各段的加载地址。
  2. 检查向量表偏移：Cortex-M系列MCU的向量表起始地址必须与程序入口对齐。在main_text_section.ldt中，确保.vector_table段也被正确放置在了0x2000偏移之后。
  3. 检查模式切换逻辑：在BleApp_HandleKeys函数中打断点，或者添加详细的串口打印，确认按键事件是否被正确捕获，mGapRole变量是否被正确切换。
  4. 检查广播参数：确认app_config.c中的广播间隔gAdvParams是否合理（如50ms-100ms），广播数据gAppAdvertisingData是否包含了OTAP的UUID。

问题二：手机能发现并连接设备，但OTAP服务列表为空或升级功能灰色不可用。

• 排查思路：
  1. 核对GATT数据库：这是最常见的原因。使用手机上的蓝牙调试App（如LightBlue）连接设备，查看其完整的服务列表。与OTAP示例工程的服务列表对比，检查OTAP服务的UUID及其下的特征（Control Point, Status, Data）是否完全一致。一个字节的错误都会导致服务不可用。
  2. 检查服务安全权限：在app_config.c的serviceSecurity数组中，OTAP服务要求的加密等级是否过高？尝试暂时降低为gSecurityMode_1_Level_1_c（无加密）进行测试。同时，在手机连接时，确认配对/加密过程是否成功。
  3. 验证事件路由：在BleApp_GattServerCallback函数中，确保所有OTAP相关的事件（特别是写操作gEvtAttributeWritten_c）都被正确路由到了OtapClient_AttributeWritten函数。可以在此函数入口加打印来验证。

问题三：升级传输过程中中断，或传输完成后设备“变砖”无法启动。

• 排查思路：
  1. 检查存储介质：如果使用外部SPI Flash，确认pin_mux.c中的SPI引脚初始化是否正确，SPI驱动是否成功初始化。可以在OtapClient_Config()之后添加Flash ID读取测试。
  2. 检查Bootloader标志区：在应用程序中，在准备写入标志和复位前，将标志区的内容通过串口打印出来。在Bootloader代码中，在启动时也打印标志区内容。确保双方对标志区地址、数据格式的理解完全一致。
  3. 镜像文件验证：确保用于升级的.srec文件本身是有效的、针对当前硬件编译的。可以尝试用这个.srec文件通过调试器直接下载到0x2000地址，看设备能否正常运行，以排除镜像本身的问题。
  4. 电源稳定性：无线升级过程耗电较大，且Flash写入时电流会有尖峰。确保设备供电充足，避免因电压跌落导致Flash写入错误或MCU复位。

问题四：升级后，新固件功能正常，但无法再次进入OTAP模式（即丢失了OTAP服务）。

• 原因与解决：这正是本文开头强调的“可持续升级”问题。这意味着你用来升级的“新固件”镜像，其工程没有集成OTAP服务。Bootloader只是机械地将收到的镜像写入应用程序区。如果这个镜像里没有OTAP服务代码，设备自然就失去了再次被无线升级的能力。
• 解决方案：确保用于生成升级镜像的工程，也必须完整集成了OTAP服务。也就是说，你的产品固件应该始终包含OTAP功能，除非这是最后一次更新。

通过以上系统的集成、测试和排查，你应该能够成功在KW38上实现一个稳定可靠的蓝牙LE OTAP功能。这个过程虽然繁琐，但一旦打通，将为产品的后期维护和功能迭代带来巨大的便利。记住，OTA功能关乎产品“生命线”，充分的测试和严谨的设计至关重要。