企业官网建设流程全解析

1. 先把这颗芯片的定位弄清楚，再谈架构

LPC4350 这颗片子，我第一次接触是被一个数据采集项目推过去的：主控既要跑高速 AD 采样搬运，又要做实时滤波和协议栈，单核 Cortex-M4 跑到 180MHz 还是被中断拖得喘不过气。当时看到它是 Cortex-M4 加 Cortex-M0 的双核组合、204MHz 主频、带 AHB 多层矩阵，第一反应是“这不就是把一颗小 MCU 塞进大 MCU 里当协处理器”，实际上手之后才发现，真正的价值不在“多了一个核”，而在 AHB 矩阵把两个核的存储访问路径和外设访问出口做了物理上的分域。这一点决定了整个软件架构该怎么搭，也决定了你后面 80% 的坑在哪里。

先把最容易误解的地方讲清楚：LPC4350 是无片内 Flash的型号。它没有内置程序存储器，代码要么放在外挂的 SPIFI 串行 Flash 里执行（通过 SPIFI 控制器做 XIP），要么在启动时被搬进 SRAM 里跑。这个特性对双核架构的影响是连锁性的——M0 侧根本没有能力自己去取指启动，它的镜像必须由 M4 先准备好、再由 M4 把它“放行”。所以在这颗芯片上，双核不是对等的，是主从关系明确的主核 + 协核，所有启动、时钟、电源、复位的控制权都在 M4 手里，M0 更像是一个被唤醒、被喂数据、干完活再回报的打工人。你在设计软件时如果不接受这个前提，硬要按对称多核的思路去做，后面一定会撞墙。

这套架构适合谁？适合那些实时性要求分层明显的场景：硬实时、低抖动的活儿（比如 SGPIO 时序生成、PWM 边沿控制、简单的状态机轮询、看门狗监控）扔给 M0，因为它没有 Flash 取指延迟的困扰、没有复杂的中断嵌套、代码小、响应确定；重计算的活儿（FFT、滤波、协议解析、文件系统、网络）留给带 FPU 和 DSP 指令的 M4。反过来，如果你的应用只是简单的控制逻辑，双核带来的调试复杂度和 IPC 开销会得不偿失，老老实实单核更省心。

1.1 为什么第二个核选 M0 而不是再来一个 M4

这个问题我当初也问过自己。答案其实很实在：成本、功耗、确定性三个因素叠加。

M0 的内核面积极小，流水线短（三级），没有分支预测、没有乱序、没有 FPU，中断延迟是固定的十几个周期，指令时序几乎可以数周期算。我在做 SGPIO 数据流的抖动测试时对比过：同样的轮询循环放在 M4 上，因为 Flash XIP 的取指预取和 AHB 仲裁会带来几纳秒到几十纳秒的不确定抖动；放在 M0 上、代码放在它自己的 SRAM 块里跑，抖动几乎就是总线仲裁的那点固定开销。这种确定性对生成精确时序、对外部器件的建立保持时间做保障，价值非常高。

另一方面，M0 的功耗远低于 M4。在待机监听场景里，让 M4 进深度睡眠、只留 M0 轮询一个低速接口，整机静态电流能压下来一大截。所以这颗芯片的双核不是“性能翻倍”的概念，而是“把不同确定性和功耗等级的任务分开安置”的概念。理解这一点，你做任务划分的时候就不会想着“把一半计算量分给 M0”这种不切实际的方案了——M0 那点算力，跑定点小循环还行，跑浮点或者复杂协议栈会很痛苦。

还有一点容易被忽略：M0 没有自己的 Flash 接口，也没挂大多数高速外设。它的代码必须驻留在 SRAM 里，这意味着它的代码空间和你的数据空间在抢同一块物理 SRAM。64KB 的片上 SRAM 在双核项目里是真的不够用，M0 镜像占个 8~16KB，两个核的栈各占几 KB，剩下的给数据缓冲和协议栈，一算就紧张。这是我踩过的第一个坑：项目初期按单核思维做预算，做到一半发现缓冲区没地方放。后面我会讲怎么规划这几块 SRAM。

1.2 无片内 Flash 带来的三个连锁约束

第一个约束是启动时间。从 SPIFI 外挂 Flash 做 XIP，上电后要先配置 SPIFI 控制器、时钟分频、读命令和 dummy cycle，才能开始取指。整个冷启动到 main 函数的时间比带片内 Flash 的型号长不少。如果你的产品要求上电后极短时间进入工作状态，得考虑把关键启动代码或者整个应用搬到 SRAM 里跑，用启动加载器从 SPIFI 搬过来。这个方案我在一个要求 50ms 内出第一帧的产品上用过，代价是 SRAM 更紧张。

第二个约束是执行带宽。SPIFI 是四线串行接口，即便跑满，顺序取指的吞吐也远不如并行 Flash。M4 有预取单元和指令缓存（LPC43xx 的 M4 侧有 Flash 加速器/预取机制），顺序代码影响不大，但频繁跳转的中断服务程序会明显吃亏。我的做法是把高频中断的 ISR 和它调用的关键函数用编译器属性放到 SRAM 里，中断响应一下就稳了。同理，M0 的代码本来就全在 SRAM，这一项它天然占优。

第三个约束是代码量必须克制。外挂 Flash 容量可以做得很大，但你如果把 M0 镜像也放在 SPIFI 里、让它去 XIP 执行，那 M0 的确定性优势就没了，而且 M0 侧的取指会跟 M4 抢 SPIFI 的访问权。所以 M0 镜像一定要在启动阶段搬到 SRAM。这就引出了下一节要讲的：镜像怎么布局、链接脚本怎么写。

2. AHB 矩阵才是这套架构真正的骨架

很多人看双核芯片只关注两个核的主频，忽略总线。LPC4350 的性能上限，很大程度上被 AHB 多层矩阵的结构决定。它采用的是多主多从的交叉结构：主设备包括 M4 的 I-Bus / D-Bus / S-Bus、M0 的 I-Bus / D-Bus、通用 DMA 控制器、以及挂在高速外设上的专用 DMA（比如以太网、USB、LCD 各自的 DMA 通道）；从设备包括 SPIFI/外部存储控制器、几块 SRAM、外设桥、SGPIO、LCD 控制器等等。矩阵的规则很简单也很残酷：任何一个从端口，在同一时刻只能服务一个主设备。不同从端口可以并行，同一个从端口要排队。

这句话是整个双核软件设计的第一性原理。你所有的“为什么这里会卡”“为什么加了核反而变慢”，答案八成在这里。

2.1 谁在抢总线：把并发关系画出来

我在纸上画过一张并发关系图，比任何文档都管用。横轴是从设备，纵轴是主设备，能并行的打勾，会冲突的标红。M4 的 D-Bus 访问 SRAM0、M0 的 D-Bus 也访问 SRAM0，这一格就是红的；M4 访问 SPIFI、M0 访问自己的 SRAM，这两格是绿的，可以真正并行。矩阵的价值就在这些绿格上。

实际影响有多大？举个我实测的例子。当时 M0 每 10 微秒要写一次共享缓冲区，M4 在做浮点滤波，数据全放在同一块 SRAM 里。理论算下来 M0 每次写只占几个总线周期，占比很低。但实测相位抖动比预期大了一倍多，原因是 M4 的浮点运算会产生密集的连续数据访问，一旦它占住那块 SRAM 的从端口，M0 的写请求就得等，等待时间不是固定的，取决于 M4 当前这串访问什么时候结束。抖动来源不是 M0 慢，而是排队时间的随机性。

解决办法不是提高优先级（AHB 矩阵的仲裁在这颗芯片上可调空间很小），而是物理隔离：把 M0 的工作缓冲挪到另一块 SRAM 上，让两个核各自访问不同的从端口。改完之后抖动立刻收敛。这件事让我明白一个道理——在这类多主总线上，减少共享比优化共享更有效。

2.2 三块 SRAM 的分工，决定了你的架构好坏

片上的 SRAM 是分块的，每块挂在自己的从端口上，块与块之间可以并行访问。这是这颗芯片最值得利用的资源，也是最容易被浪费的资源。我在项目里形成的分配原则是：

• M0 私有区：放 M0 的向量表、代码、栈和它自己的小缓冲。这块内存 M4 尽量不碰，只在初始化时写入镜像。
• M4 私有区：M4 的栈、堆、大数组、协议栈缓冲区。M0 完全不访问。
• 共享区：只放核间通信的数据结构（邮箱、环形缓冲、状态标志），而且结构要小、访问要短、频次要可控。

这个分法的核心思想是：共享区越小，争用越少，调试越容易。我见过有人为了省 SRAM，把两个核的栈都放在同一块里，结果出现极其诡异的随机崩溃——M0 栈溢出踩到了 M4 的数据，现象是 M4 莫名其妙算出 NaN。这类问题排查起来能让人崩溃，因为它不报错，只是数据被悄悄改掉。

具体的容量分配，我的经验值是这样：M0 镜像（代码+常量）留 8~12KB，M0 栈 1~2KB，M0 私有缓冲 2~4KB；共享区 2~4KB 足够做几个环形缓冲加邮箱；剩下的全部给 M4。这个比例不是拍脑袋，是按 M0 干“简单但频繁”的活来估的——它的代码天然小，但缓冲要够它攒一批数据再一次交给 M4，避免频繁触发中断。

注意：SRAM 分块的边界一定要写进链接脚本，并且在代码里用编译期断言（比如静态断言检查某个数组不跨块）保护住。运行时才发现跨块，问题就晚了。

2.3 从端口的分域和 M0 的可达范围

M0 不是万能的，它看不到 M4 能看到的全部地址空间。哪些外设 M0 能访问、哪些不能，用户手册里有一张专门的表，做架构设计前必须把这张表打印出来贴在桌上。大致规律是：挂在 M0 可达从端口上的那部分外设（一些定时器、SGPIO、部分串行接口、GPIO 中断相关逻辑）M0 能用；SPIFI、LCD、以太网、USB、SDIO 这类高速外设，M0 够不着。

这个限制其实挺好，它天然帮你划了边界：凡是要碰高速外设的活，必须在 M4 侧做。所以任务划分不要幻想“让 M0 去收以太网包”，它连 MAC 都摸不到。M0 的定位就是那些挂在低速外设上、需要确定性响应的活。

还有一个细节新手常犯：M0 访问外设时，时钟必须由 M4 侧使能好。M0 自己没有时钟控制模块，所有外设时钟、电源域都在 M4 的管辖下。我遇到过一次 M0 读某个定时器一直返回 0，查了半天以为是地址映射问题，最后发现是 M4 在初始化时漏了一句时钟使能。这类“M0 看起来坏了其实是 M4 没配置”的问题，在双核调试里占了很大比例，后面排查章节我会专门列。

2.4 算一笔带宽账，别凭感觉优化

做嵌入式久了容易凭感觉判断“这个够快”，但在多主总线上必须算账。方法不难：单从端口的理论峰值带宽 = 总线时钟频率 × 每周期字节数。总线跑 204MHz、32 位宽，理论峰值就是 204M × 4B ≈ 816MB/s。注意这是单端口的峰值，而且只有在没有冲突、没有等待状态、连续突发传输的情况下才能逼近。

拿一个实际场景算：M0 每 10 微秒写 32 字节到共享区，平均带宽需求是 32B / 10μs = 3.2MB/s。相对于 816MB/s 简直是零头。看着完全没问题对吧？但峰值占用不是这么算的——32 字节如果是一次突发传输，它会在极短时间内连续占用几个总线周期，这段时间里 M4 对这个端口的访问全部阻塞。如果 M4 正好在做需要低延迟响应的操作（比如响应一个高优先级中断去读同一块 SRAM 里的变量），它就得等这几个周期。所以要看的不是平均带宽，而是峰值占用和阻塞时长的组合。

我的做法是给每个共享访问算两个数：单次传输的最大阻塞周期数，以及每秒钟这类传输发生多少次。前者决定最坏延迟，后者决定延迟发生的频率。两者相乘，你就知道这个共享访问会不会影响实时性。这套算法不精确，但足以让你在做架构设计时避开明显的坑，比事后用示波器抓瞎强得多。

3. 双核启动流程与工程构建

这颗芯片的启动流程是我见过最容易出错的环节之一，因为它不像对称多核那样有个统一的引导流程，M0 完全是被动等待的。

3.1 复位之后发生了什么

上电复位后，只有 M4 开始执行。它从启动地址取向量表、初始化栈指针、跑启动代码，然后进 main。此时 M0 处于保持复位或者等待状态，它的时钟可能还没使能，它的地址空间可能还没建立映射。

要让 M0 跑起来，M4 需要按顺序做这几件事：

1. 使能 M0 的时钟，解除它的复位保持；
2. 把 M0 的镜像从存储介质（SPIFI 里或者 M4 的镜像段里）拷贝到 M0 将要执行的 SRAM 区域；
3. 通过配置寄存器把 M0 的地址空间建立映射，让它复位后能从正确的地址取到向量表；
4. 在 M0 的向量表里填好初始栈指针和复位向量；
5. 用内存屏障指令保证前面所有的写入对其他核可见；
6. 触发 M0 启动（释放复位或写启动事件寄存器）。

这里每一步都可能出问题。第 2 步的坑是拷贝完忘了做 cache/写缓冲清理，如果 M4 侧有写缓冲，某些写入可能还停在缓冲里没落到 SRAM，M0 启动后取到的指令就是旧的或者空的。这类问题现象非常诡异：单步调试能过，全速跑就崩。解决方式是在跳转前加数据同步屏障，必要时做一次缓存清理。

第 3 步的映射是最容易搞混的。M0 有自己独立的地址视图，它看到的 0x00000000 未必等于 M4 看到的 0x00000000。芯片里有一组配置寄存器负责这个映射，M4 通过写这些寄存器决定 M0 的哪段地址映射到哪块物理存储。我建议的做法是：固定一种映射方案，写进文档，全项目不再改动。因为一旦映射关系变了，M0 侧所有绝对地址、所有链接脚本都要跟着调整，牵一发动全身。

提示：映射相关的寄存器具体名字和位定义，不同批次的芯片手册表述略有差异，务必以你手上那版用户手册的配置寄存器章节为准，别照抄网上的代码。

3.2 M0 镜像怎么放，才不会到处踩内存

我的实践是把 M0 的镜像作为一个“数据段”嵌进 M4 的工程里，链接时分配在 M4 镜像的常量区；M4 启动时把这段数据拷到 M0 的执行区，然后放行。这样做的好处是只需要一个烧录文件，产线不用管两个镜像怎么合并，升级时也不会出现两个镜像版本不匹配的情况。

代价是 M4 的镜像变大了，从 SPIFI 加载的时间变长。如果对启动时间敏感，可以改成把 M0 镜像单独放在 SPIFI 的一个固定分区，M4 启动时用 SPIFI 控制器直接读过来。两种方案我都用过，前者简单，后者启动快，看项目取舍。

具体做法上，给 M0 镜像定义一个专属的段，用链接脚本把它定位，同时在 C 里用一个符号把段的起止地址导出来，启动代码用这两个符号做拷贝。拷贝完必须校验一下长度和校验和，我加过这个检查之后抓到过一次因为编译配置错误导致 M0 镜像被截断的问题——不校验的话，现象是 M0 跑飞或者卡在 HardFault，完全看不出根因。

3.3 链接脚本与向量表的两个硬性要求

双核工程的链接脚本比单核复杂，但核心就两条：各段的物理归属明确，跨核共享的符号地址唯一。

第一条的意思是，M0 的代码段、数据段、栈必须落在 M0 能访问的、且你打算给它用的那块 SRAM 上；M4 的栈、堆、共享区同理。我习惯在链接脚本里用 MEMORY 区域把它们切干净，然后在代码里放静态断言：比如检查 M0 栈顶不越界、检查共享缓冲不落在 M0 的私有区。这些断言在编译期生效，比运行期崩溃好一万倍。

第二条是符号一致性的问题。共享区的变量在两个核的代码里都会引用，如果两边编译时的地址不一致，那就是各写各的。保证一致的办法是共享区的布局用一个共用的头文件描述，两个工程都引用它，链接脚本里把这块区域的起始地址固定成同一个常量。我见过有人在两个工程里各自定义了一遍结构体，某一方加了个字段没同步，结果写进去的数据错位，查了两天。

向量表这一块，M0 的向量表必须放在它地址空间的起始位置（或者按它的向量表偏移寄存器设定），并且复位向量要指向 M0 的入口函数。M4 在拷贝镜像时，向量表的第一个字是初始栈指针，第二个字是复位向量，这两个值必须由 M0 的链接结果决定，不能手写硬编码。我通常让链接脚本自动生成，启动代码只负责原样拷贝。

3.4 构建系统怎么组织才不会互相打架

两个核的代码放在一个工程里还是两个工程？我用过两种，现在倾向于一个仓库、两套编译配置、一次构建出两个产物，最后合并。

单工程的好处是共享头文件天然同步，改一个结构体两边都重新编译，不会出现版本错配。做法上给两个核各自的源文件目录，用编译配置区分；共享的头文件和共享区的定义放在公共目录。构建脚本先编 M0、生成 bin，再把这个 bin 转成 C 数组或者链接进 M4 的段，最后编 M4。

这里有个务实的技巧：把 M0 的构建产物生成时间和校验和写进 M4 的镜像里，运行时打印出来。这样在排查“到底跑的是哪个版本的 M0 镜像”时，一眼就能看出来。我吃过这个亏——调试器里加载的是新的 M4 镜像，但 M0 那段数据是旧的，两边协议对不上，现象是通信一直超时，浪费了大半天。

4. 核间通信，三种落地方式的取舍

双核架构里，IPC 的设计决定了整体代码的复杂度。这颗芯片没有硬件消息队列，没有共享缓存一致性协议，全靠软件在共享内存上搭。听起来原始，其实够用，前提是你选对模式。

4.1 共享内存加邮箱中断：最朴素也最可靠

最小可用的 IPC 就是“一块共享结构 + 一根中断线”。发送方把数据写进约定的结构，然后触发对方的中断；接收方在中断里读结构，读完后清标志。

中断的通路是这样的：M4 往配置寄存器里写一个事件，M0 侧的 NVIC 上就会有一根专用中断线被置起；反过来 M0 也是写寄存器，M4 侧的 NVIC 收到中断。整个机制非常轻，触发延迟在百纳秒级，比任何软件轮询都快。

关键设计点是中断里只做最少的事。我的规矩是中断里只置一个软件标志或者往环形缓冲里塞一个索引，实际的数据处理放到主循环或者低优先级任务里做。原因很实在：M0 的中断优先级数量有限，M4 侧的中断延迟也受总线争用影响，中断里做重活会把整个系统的响应性拖垮。

还有一个细节必须处理：中断的清除顺序。发送方触发中断后，如果接收方在读完数据之前就把中断标志清了，而发送方此时又发了第二次，就会丢事件。稳妥的做法是接收方先读数据、再清标志、然后再检查一次有没有新数据；发送方在数据写完并加了内存屏障之后再触发中断。这个顺序错了，现象就是“偶尔丢一帧”，而且复现率极低，非常折磨人。

4.2 环形缓冲：数据流场景的主力

如果两个核之间传的是连续数据流（采样值、串口字节、控制指令序列），用单变量邮箱就不够了，得上环形缓冲。单生产者单消费者的环形缓冲在双核环境下其实很好实现——只要读写指针各自只被一个核修改，就不需要加锁。

我的实现是一个头一个尾两个索引，生产者只改头、消费者只改尾，都用“无符号整数自然回绕”的方式处理，容量取 2 的幂，索引用位与代替取模。这套东西的正确性依赖一个前提：索引的读写必须是原子的。32 位对齐的单字读写在这颗芯片上是原子的，所以只要索引是 32 位、地址对齐，就不用关中断。

但内存序是个坑。编译器的优化和 CPU 的写缓冲都可能让“先写数据、后更新头指针”这个顺序在别的核看来是反的。解决办法是在更新头指针之前插入一个写屏障，确保数据先落地。这一步我在项目里是强制要求的，写在代码规范里，评审时必查。少了这个屏障，代码在调试版本下跑得好好的，开了优化就偶发数据错乱。

容量规划也要算。假设 M0 每 10μs 产生 32 字节，M4 每 1ms 批量消费一次，那两次消费之间最多攒 100 次、3200 字节。缓冲就得给到 4KB 以上留余量。这个账必须提前算，不能等到运行起来发现溢出再改——改容量意味着改链接脚本、改共享区布局，返工成本高。

4.3 临界区和内存序，双核下的真正难点

单核时代的临界区就是关中断，双核时代这招只对一半。关中断只能挡住本核的并发，挡不住另一个核同时访问同一块内存。真正的临界区需要软件锁。

这颗芯片有硬件信号量外设（一组可以原子置位/测试的寄存器），我用它做过互斥。用法很简单：尝试置位，成功就进临界区，失败就重试或者等。但要注意锁的粒度和持锁时间。我见过在临界区里做浮点运算的代码，另一个核等锁等到超时。经验是：临界区里只有几条赋值语句，超过十几条指令就该重新设计数据结构了。

更根本的解决办法是用数据结构消除锁。单生产者单消费者模型不需要锁，双缓冲切换只需要一个原子指针交换，消息队列可以用环形缓冲实现无锁。我在后来的项目里基本把锁的使用压到了最低，只在初始化和错误恢复路径上用。这比调优锁的性能有效得多。

内存序的坑我在上一节提了一半，这里补完。双核环境下的可见性问题分两层：编译器层和硬件层。编译器层用编译器屏障挡住重排，硬件层用数据同步屏障保证写入真正落到内存而不是停在写缓冲里。这两层都得有。我的习惯是封装成一个“发布”宏和“获取”宏，所有跨核的数据传递都必须走这两个宏，代码评审时看到裸的赋值就要打回去。这套约束一开始团队里有人嫌麻烦，出过一次事故之后就没人抱怨了。

5. 实战拆解：采集与处理的分工实例

光讲原理太空，拿一个我做过的完整例子走一遍。场景是：外部器件通过同步串行接口连续输出采样数据，采样率要求稳定，M4 侧要做多通道滤波和特征提取，然后把结果通过串口上报。

5.1 任务划分：为什么这么切

划分的依据是确定性要求和计算量两个维度。采样接收要求严格的时间确定性，抖动直接影响采样间隔的均匀性；滤波和特征提取计算量大，但不要求微秒级响应。所以采集放 M0，处理放 M4。

M0 侧的工作是：配置好串行接口，用一个定时器产生采样节拍，每个节拍到就把收到的数据塞进环形缓冲；缓冲攒够一批，就触发一次 M4 的中断；同时还要跑一个超时监控，如果 M4 太久没来取数据，就置一个溢出标志。

M4 侧的工作是：收到中断后从环形缓冲取一批数据，做多通道滤波，算特征值，格式化后通过串口发出；如果发现缓冲接近满，就临时提高取数频率；如果发现 M0 报了溢出，就记录错误计数。

这个切法有个隐含的好处：M4 侧的滤波算法可以随便改、随便加复杂度，完全不影响采样时序。这就是双核架构最实在的价值——把“不能慢”和“算得多”彻底解耦。

5.2 M0 侧的采集循环怎么写才稳

M0 的代码我坚持三个原则：不放浮点、不调用库函数、循环里不做分支预测不友好的跳转。

采集节拍用一个硬件定时器驱动，但我不在定时器中断里做搬运，而是让主循环轮询定时器的状态标志。原因是 M0 的中断入口有固定开销，中断嵌套还可能引入额外延迟；轮询的方式虽然占着 CPU，但时序是完全可预测的。M0 本来就没什么别的事干，浪费一点 CPU 换确定性很划算。

搬运的时候直接读外设的数据寄存器，写进环形缓冲。写完更新头指针，加一个编译器和硬件屏障。整个过程大概十几条指令，跑起来之后我用 GPIO 翻转测过，从节拍标志置位到数据入缓冲的延迟抖动在几十纳秒量级，完全够用。

触发 M4 的时机要控制。如果每来一个样本就触发一次中断，M4 那边会疲于奔命。我的做法是攒够半批再触发，或者用一个较低的频率做“心跳”触发。触发次数少，M4 的中断开销就摊薄了。这里有个平衡点要试：触发太稀疏，M4 那边一次要处理的数据多，延迟大；太频繁，开销上去了。我一般先按“每 1ms 触发一次”起步，再看实际负载调。

5.3 M4 侧的流控和背压处理

M4 处理不过来怎么办？这是数据流系统必然面对的问题，必须提前设计。

我的方案是三级响应：环形缓冲占用超过 60% 时，M4 记录一次“水位告警”；超过 85% 时，M4 临时跳过一部分非关键的处理步骤（比如降低滤波阶数或者减少上报字段），保证取数速度；如果 M0 报溢出，M4 记错误计数并在上报里带出来，方便现场定位。

这套机制的价值在于系统不会因为偶发过载就崩掉。我见过不做背压设计的实现，一旦 M4 被别的高优先级任务占住，缓冲直接溢出，数据丢失且没有任何记录，现场排查完全没线索。加了水位监控之后，即便丢数据也有据可查，还能从错误计数判断是不是特定工况触发的。

水位判断的读写在 M4 侧做，只读共享区的头尾指针，不写。M0 侧只写不读水位。这样两个核对共享区的访问保持单向，天然避免了很多竞态。

5.4 时序核算：把账算在纸上

上线前我把整条链路的时序算了一遍：

采样周期 10μs，每周期 32 字节，单周期内 M0 的搬运耗时约 20 个 CPU 周期（含总线等待），按 204MHz 算是 100ns 左右，占采样周期的 1%，余量充足。缓冲容量 4KB，可容纳 128 个周期的数据，即 1.28ms 的突发容忍。M4 每 1ms 取一次，每次处理 100 个样本，滤波算法实测耗时 300μs 左右，占用 30% 的 CPU，留了充足余量给其他任务。

中断延迟方面，M0 触发到 M4 进中断，跨核中断加总线同步，实测在 1μs 以内。加上 M4 可能正在执行更高优先级的中断，最坏情况按 5μs 估，相对于 1.28ms 的缓冲余量完全不是问题。

把这些数写进设计文档，后面任何人改代码都能对照着看有没有破坏余量。我强烈建议每个双核项目都做这么一张表，它比一堆注释有用得多。

6. 调试与问题排查：那些文档里不会写的经验

双核调试是这类项目里最费时间的部分，因为常规的单核调试手段很多不适用。分享几个我认为最有价值的做法。

6.1 只有一个调试器探针，怎么调两个核

这颗芯片的调试结构里，M0 的调试访问是通过 M4 侧桥接的，你通常只有一个物理调试接口。这意味着你不能像对称多核那样同时下两个断点。我的做法是轮流调试：调试 M0 的时候把 M4 设成运行或者设一个延迟断点，反过来也一样。调试器一般都支持选择调试目标核，切换一下就行。

更实用的技巧是用共享内存做日志。在共享区开一块环形日志缓冲，两个核都往里面写带时间戳的事件（进入某函数、收到某中断、状态切换），然后在 M4 侧运行一个命令把日志打印出来，或者在没有调试器的时候存到外部存储里。这招在排查“偶发卡死”“数据错乱”这类时序问题时几乎是唯一有效的手段，因为断点会改变时序、掩盖问题，日志不会。

日志本身也要控制开销。我一般用固定的二进制记录格式，每条几字节，写指针原子更新，不做格式化。解码在 PC 端做。这样对实时性的影响可以忽略。

6.2 常见故障速查表

我把这几年遇到的双核问题整理成一张表，出问题按这个顺序过一遍，能省不少时间：

这张表里，我认为最难查的是“单步能过全速崩”和“数据偶发错乱”这两类，因为它们都不报错。共同点都是时序相关的软件问题，靠断点永远查不出来，只能靠日志、靠代码审查、靠把可疑的共享点全改成有屏障的发布/获取模式。

6.3 几条我踩过坑才信的经验

第一条：别在 M0 上跑复杂代码。我曾经把一段协议解析放到 M0 上，理由是“M4 太忙了”。结果 M0 频繁进出中断、频繁访存，把它自己的确定性优势全毁了，还因为代码变大挤占了缓冲空间。后来把这段挪回 M4，M0 只做纯搬运，两边都舒服了。M0 就该干“简单但必须准时”的活，这是它的全部价值。

第二条：共享区的每一个字段都要写清楚谁写谁读。我在共享结构体的每个字段上加注释，标明方向和访问方，这个习惯救过我很多次。双核 bug 有相当一部分是“双方都以为自己可以写某个字段”。约定成单向写入之后，这类问题基本绝迹。

第三条：上电顺序和初始化顺序要画成图。M4 初始化时钟、初始化外设、初始化共享区、加载 M0 镜像、放行 M0，这个顺序里任何一步提前或延后都可能出问题。比如 M0 在共享区还没初始化完就开始写，写进去的初始状态就被覆盖了。我在代码里用一个明确的“启动完成”标志位做同步，M0 启动后先等这个标志，M4 把该准备的都准备好再置位。

第四条：性能问题优先怀疑总线，别急着改算法。我见过团队花了几天优化滤波算法，最后发现瓶颈是两个核在抢同一块 SRAM 的访问端口。先把数据挪到不同的块上试试，往往几行改动就能解决。

最后分享一个我在实际项目里养成的小习惯：在共享区的头部固定放一个版本号和校验字段，两个核启动后都读一遍，不一致就点亮一个错误指示灯并且拒绝进入正常工作状态。这个检查只花几十行代码，但它能在升级、产线烧录、调试器混用镜像这些场景下第一时间把问题暴露出来，而不是等到运行半小时之后才莫名其妙地崩。踩过那次“两个镜像版本不匹配查了一整天”的坑之后，这个习惯我就再也没丢过。