企业官网建设流程全解析

搞嵌入式最怕什么？最怕硬件、软件、芯片手册都看起来没问题，但板子上电之后就是不干活，而且问题出在最基础的 SPI 通信上。前几天我就经历了一次这样的“灵异事件”：用的是 STM32G031 这颗性价比极高的小芯片，去控制一颗 MT6835 音频功放芯片，结果 SPI 第一次通信死活不通。逻辑分析仪明明抓到了波形，寄存器状态却全乱，读回来的数据不是 FF 就是 00，那感觉就像在跟一个看不见的鬼较劲。

这篇文章就把这次完整的排查过程摊开来讲。从方案选型、CubeMX 配置、SPI 关键参数，到真正定位问题的那几步操作，全部复盘一遍。如果你也在调 STM32 和某个带 SPI 接口的从机芯片，或者正准备用 MT6835 这类功放芯片，这篇文章能帮你少走我走过的弯路，尤其是那几个 CSP 极性和相位、引脚复用映射、上电时序的坑，真的是教科书里不会明说、但实际必踩的地方。

1. 项目背景与方案选型：从一次“灵异事件”说起

先说清楚我这次在做什么。项目需要做一个小体积的音频输出模块，主控选型时我看上了 STM32G031，原因很直接：这颗芯片是 Cortex-M0+ 内核，主频 64MHz，价格在 STM32 家族里属于非常亲民的一档，而且封装小、功耗低，特别适合做音频控制这类任务。模块里要控制一颗 D 类功放芯片 MT6835，这颗芯片支持通过 SPI 接口配置增益、滤波模式、开关机时序等寄存器。MT6835 是 MBI（聚积科技）推出的音频功放方案，名字可能不如 TI 的 TAS 系列响亮，但在小功率音频产品里用得不少，数据手册里的 SPI 时序图说实话藏了不少含糊之处。

选 SPI 而不是 IIC 的原因也很简单：MT6835 支持的是标准 SPI 从机模式，而且它的寄存器配置是“地址+数据”的长帧格式，用 IIC 反而不方便；SPI 全双工通信速度快、时序明确，对寄存器批量读写操作更直接。再加上 STM32G031 的 SPI1 外设是现成的，主控这边几乎不用额外开销。这种选型在很多音频模块设计里都很常见：MCU 做控制和协议解析，功放芯片做信号放大，两者用一条 SPI 总线连接，简单、干净、时序可控。

但正因为“看起来简单”，这次调不出来才格外闹心。我把 CubeMX 里 SPI 引脚配置好，代码也写了一版标准的寄存器读写函数，上电后读状态寄存器，返回值却是 0xFFFF；写配置寄存器，再读回来完全对不上。第一反应是怀疑芯片坏了，焊下来换了一颗，问题依旧；又以为是 SPI 速率太高，从 1MHz 一路降到 100kHz，还是不通。那时候脑子里真的全是问号：波形看起来有啊，怎么就是不通？

后来的事实证明，问题根本不在“通不通”这个层面，而在于“通的姿势不对”。ST 的 MCU 和 MT6835 这类音频功放芯片，双方对 SPI 时钟极性和相位的理解，如果差一个边沿，那就是天壤之别。你以为你在用 Mode 0，其实芯片在等 Mode 1，结果就是每一 bit 都错位，寄存器读出来当然是乱七八糟。这个道理我后面会详细拆，先在这里留个引子。

1.1 为什么 STM32G031 和 MT6835 是常见搭配

如果你做音频模块设计，ST 的低功耗小封装 MCU 加上 MBI 的功放，其实是性价比很高的组合。STM32G031 不需要跑复杂操作系统，只负责初始化功放寄存器、处理音量命令、检测过流过热状态，资源完全够用。这颗 MCU 的 SPI1 最高可以跑到几十 MHz，对 MT6835 这种几十 kHz 到几 MHz 级别的功放配置需求来说绰绰有余。它的 LQFP 封装和 TSSOP 封装都很适合做小尺寸 PCB，成本上也压得住。

MT6835 这颗功放芯片则胜在集成度高，外围只需要很少的阻容元件，输出功率在小音箱、便携设备里够用。它的 SPI 从机接口设计得比较“传统”，支持标准的 8 位/16 位传输，但从机内部寄存器地址并不是简单的线性映射，手册里那几张寄存器表看多了容易眼花。说句实在话，MBI 的数据手册和 ST 的参考手册放在一起，阅读体验差距挺明显的，很多时序细节是字缝里读出来的。比如它的 SPI 片选信号要求在寄存器帧头前至少拉低若干个 SCLK 周期，这种要求在常规 SPI 通信里不常见，不看时序图根本发现不了。

信息在传输之前，主从双方必须约定好几件事：时钟空闲电平是高还是低（CPOL）、数据在哪个边沿采样（CPHA）、先发高位还是低位（MSB/LSB）、帧长度是 8 位还是 16 位、以及片选是低有效还是高有效。这些约定全部对了，SPI 通信才能成立；任何一个错位，现象就可能和我遇到的一样：波形完美、数据狗屁不通。

1.2 这次调试的核心难点预估

在动手写代码之前，我其实应该先列一个风险清单，但当时经验主义作祟，觉得 SPI 嘛，配过一百遍了，直接上。结果就是连续折腾了好几个小时。事后复盘，这个项目的核心难点主要集中在这几个地方：

第一，引脚复用映射。STM32G031 是一颗小封装芯片，引脚功能复用非常多，SPI1 的信号不只在固定的几个脚上出现。CubeMX 虽然会自动分配，但如果你手动指定了某个引脚给 SPI1，却没对齐复用功能表，那引脚就只是个普通的 GPIO，数据根本送不出去，还会给你一种“代码没问题”的错觉。

第二，时钟极性和相位的匹配。这是本次事故的头号元凶。MT6835 的数据手册里对 CPOL/CPHA 的描述比较隐晦，只有一张时序图和一句话“Data is latched on the rising edge of SCLK”，但这句话需要结合芯片内部移位寄存器的设计去理解。如果像默认那样用 Mode 0（CPOL=0, CPHA=0），上升沿采样，看上去对上了，实际却会因为前导比特位的原因出错。

第三，上电时序和片选时序。音频功放芯片通常有严格的 enable 时序，MT6835 要求先上电、稳定之后再拉低 CS 进行第一次通信。如果 MCU 在功放还没 ready 的时候就把第一个 register 写进去，这次写入会被吞掉，而且后续状态会乱掉。这个坑和 SPI 协议本身无关，但比协议更隐蔽，因为不是每次都必现，一旦出现就会让人觉得是芯片“抽风”。

2. 先搞懂 SPI 的基础约定：时序、模式、从机侧的真实需求

很多人调 SPI 调不出来，第一反应是查接线、查代码、查芯片手册里的寄存器表，但往往忽略了最基础的东西：SPI 是一套“约定”通信，主从两侧对时序的理解必须完全一致。这个理解如果不一致，代码再对也没用。我先花一点篇幅把这次涉及到的 SPI 关键点说清楚。

2.1 SPI 四种工作模式：CPOL 和 CPHA 是怎么影响通信的

SPI 没有类似 IIC 那样的应答机制，也没有完善的错误帧检测，它之所以快，就是因为把约定前置了。四个工作模式由两个参数决定：CPOL 决定 SCLK 空闲时的电平，CPHA 决定数据采样沿。很多初学者只看文字容易搞混，我自己有个口诀：先看空闲时钟是高还是低（CPOL），再看第一个边沿是采样还是翻转（CPHA）。

通俗点说，如果把 SCLK 想象成一把尺子的节拍，CPOL=0 就是节拍空闲时是低电平，CPOL=1 就是空闲时是高电平。那么 CPHA=0 表示在第一个边沿采集数据，CPHA=1 表示在第二个边沿采集数据。具体对应关系：

• Mode 0：CPOL=0, CPHA=0，空闲低，第一个边沿（上升沿）采样。这是绝大多数 SPI 从机默认用的模式。
• Mode 1：CPOL=0, CPHA=1，空闲低，第二个边沿（下降沿）采样。
• Mode 2：CPOL=1, CPHA=0，空闲高，第一个边沿（下降沿）采样。
• Mode 3：CPOL=1, CPHA=1，空闲高，第二个边沿（上升沿）采样。

MT6835 数据手册里有一张典型的 SPI 读时序图，SCLK 空闲是低电平，数据在 SCLK 上升沿被锁存。这句描述看起来是 Mode 0，但仔细看时序图里的“Address Phase”和“Data Phase”交接处，你会发现它在前缀阶段其实用了下降沿来更新数据线，而采样是在上升沿。这种“更新沿”和“采样沿”如果主控没有对齐，哪怕读出来的波形看起来连续，实际字节边界也是完全错开的。

根据我调试后的实际结果，MT6835 正常工作在 Mode 0 下确实是可以的，但前提是你必须在 CS 拉低之后、发送有效地址位之前，主动插入一段延时（或者发送若干个 0 字节），让芯片内部的 SPI 接收状态机稳定下来。否则第一个字节就是废的，后续数据处理全乱。这个细节手册没写，但实测很重要。

2.2 片选信号 CS：硬件片选和软件片选的区别与陷阱

SPI 的 CS 是低有效，主控把 CS 拉低，表示“从机你注意，我要开始跟你说话了”；拉高，表示“本轮通信结束”。别看这个逻辑简单，实操里片选的坑特别多。STM32G031 的 SPI1 有两种片选方式：硬件 NSS 和软件片选。硬件 NSS 是外设自己控制片选引脚，不需要 CPU 参与；软件片选则是把 CS 当作普通 GPIO，在 SPI 传输前手动拉低，传输完再拉高。

我建议大多数人优先使用软件片选，理由有三点：第一，硬件 NSS 在多字节连续传输时，片选时序往往是每个字节传输完成之后自动拉高一次，这会导致从机以为每次只有一个字节的事务，对于 MT6835 这种“地址+数据”的长帧寄存器配置来说非常致命；第二，硬件 NSS 引脚和 SPI 时钟之间如果存在相位差，尤其是在低速 SPI 下，容易出现毛刺，导致从机误动作；第三，软件片选可以让你精确控制 CS 拉低的时机，插入延时或者 dummy 字节都更方便，调试的时候还能用 GPIO 翻转来辅助测量。

当然，软件片选也有自己的问题，最大的坑是：如果 CS 拉低之后 CPU 被中断或者其他任务卡住了，迟迟没有启动 SPI 发送，从机就会一直处在一个伪等待状态，可能自己超时退出通信，也可能误判成一次异常帧。所以软件片选配合阻塞式发送或 DMA 时，要保证 CS 拉低到 SPI 启动之间的间隔尽量短且稳定。

2.3 SPI 和 IIC 有什么区别：为什么这里不选 IIC

有这个疑问的人不少。SPI 和 IIC 都是串行通信，但设计哲学完全不同。IIC 是半双工、两线制（SCL+SDA）、有应答机制、有器件地址寻址，支持一主多从通过地址区分；SPI 是全双工、四线制（SCLK+MOSI+MISO+CS）、无应答机制、靠独立片选区分设备。

放到这个项目里，MT6835 是典型的寄存器型从机，需要频繁读写单个寄存器，SPI 的优势在于全双工和速度。IIC 虽然也能做寄存器读写，但每次都要带器件地址、寄存器地址、数据、应答位，协议开销大；而且 IIC 的上拉电阻、电平转换在音频模块这种可能在复杂电磁环境里工作的板子上，反而更容易受干扰。SPI 的 CS 信号则天然就是一个“本设备选中”的物理门闩，抗干扰能力和时序确定性都更好。

所以这个项目用 SPI 而不是 IIC，是合理的。但这也意味着，一旦 SPI 时序不匹配，你连一个“从机反馈 NACK”的报错机会都没有，纯靠主控自己核对读回的数据，排错难度就上去了。

3. CubeMX 配置与代码实现：引脚映射和参数设置才是第一道坑

现在开始进入实操环节。这里会把我这次项目里 STM32G031 和 MT6835 之间 SPI1 的完整配置过程、代码骨架、以及踩过的引脚映射问题讲透。如果你是照着 CubeMX 从零开始配，一定不要跳过这一节。

3.1 CubeMX 里的引脚分配和 GPIO 复用

STM32G031 的很多引脚是多功能复用的，比如 PA5、PA6、PA7 既可以做普通 GPIO，也可以是 SPI1 的 SCK、MISO、MOSI。Open 开 CubeMX，选择 STM32G031 型号之后，在 Pinout & Configuration 界面左侧找到 SPI1，激活它。此时 CubeMX 会自动给你分配一组默认引脚，多半是 PA5（SCK）、PA6（MISO）、PA7（MOSI），这个默认分配通常没问题。

但要注意一个细节：CubeMX 自动生成代码时，会把这些引脚的模式设置成 Alternate Function（AF）模式，并在 GPIO 配置里填好对应的复用号。如果你在 CubeMX 里手动改过引脚，比如把 SCK 挪到 PB3，那你必须确认 PB3 的复用功能表里确实有 SPI1_SCK。否则，即使你在软件里把 SPI1 使能了，引脚仍然只是个普通输入输出，时钟信号根本不会出现在引脚上，这就是所谓的“引脚映射”问题。

我当时犯的错误是，PCB 设计时为了走线方便，把 SCK 接到了 PA5，MOSI 接到了 PA7，但 CubeMX 里因为工程模板冲突，SPI1 又被分配到了另一组引脚。结果我烧录代码后发现 SCK 引脚上有波形但极其微弱，用万用表一量，电平根本没翻转，后来查看生成的 GPIO 初始化代码才发现，CubeMX 实际上把 PA5 配置成了输入模式，SPI1_SCK 直到那时才暴露问题。解决办法很简单，在 CubeMX 里手动把 SCK 引脚强制锁定到 PA5，用 Ctrl+Click 指定功能，然后重新生成代码即可。

3.2 SPI 参数设置：时钟频率、位序、极性和相位的选择

CubeMX 的 SPI 配置界面里，Parameter Settings 那一栏需要逐项确认。对这次项目，建议这样设：

• Mode：Transmit Only Master（或 Full-Duplex Master，根据你是否要读寄存器来选）
• Hardware NSS Signal：Disable（用软件片选）
• Data Size：8 Bits
• First Bit：MSB First（MT6835 寄存器地址和数据的位序都是高位在前）
• Prescaler：先选 64 或 128，把时钟压到 1MHz 以下调试，跑通之后再慢慢提高
• CPOL：Low（空闲低）
• CPHA：1 Edge（第一个边沿采样，对应 Mode 0）

这几个参数里，最容易出问题的是 CPHA。很多 STM32 的 SPI 从机芯片默认是 Mode 0，也就是 CPHA=1 Edge，但少数音频芯片特别挑剔，要求 Mode 1。我的经验是：如果波形看起来正常但数据错乱，首先去改 CPOL 和 CPHA 的组合试试，这比怀疑芯片坏了快得多。

另外，Transmit Only Master 和 Full-Duplex Master 对 MISO 引脚的处理是不同的。MT6835 支持寄存器回读，而且回读对排错非常有价值，所以我强烈建议你选用 Full-Duplex Master，不要省掉 MISO。即使最初不需要读数据，调试时能读回寄存器状态，能帮你快速区分是主控发送问题还是从机接收问题。

3.3 初始化代码和寄存器读写函数的基本框架

CubeMX 生成基础代码后，我会在 SPI 初始化函数里手动增加一步：禁用 SPI、配置好寄存器、再使能 SPI。这个步骤平时没必要，但在我这次调试里帮助很大。大概长这样：

void MX_SPI1_Init(void) { // CubeMX 生成的初始化代码... // 加入手动复位 SPI 状态 __HAL_SPI_DISABLE(&hspi1); // 冷却一段时间，确保外设状态清零 HAL_Delay(1); __HAL_SPI_ENABLE(&hspi1); }

然后是寄存器读写函数。我的做法是：针对 MT6835 的 SPI，写一个通用的 16 位帧发送函数，其中高 8 位是寄存器地址，低 8 位是数据。但要注意，MT6835 的寄存器访问格式要看手册，有的寄存器是“先写地址、再写数据”两个 8 位块，有的需要拼成一个 16 位帧。这次项目用的是单 16 位帧方式，CS 在整个帧期间保持低电平。核心代码如下：

uint16_t MT6835_WriteRead(uint16_t regAddr, uint16_t data, uint8_t isRead) { uint16_t frame = 0; uint16_t rxData = 0; // 片选拉低 HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); // 构建 16 位帧 frame = (regAddr << 8) | (data & 0xFF); if (isRead) { frame |= 0x8000; // 假设最高位是读标志，具体以 MT6835 手册为准 } // 发送帧，同时接收从机数据 HAL_SPI_TransmitReceive(&hspi1, (uint8_t *)&frame, (uint8_t *)&rxData, 2, 100); // 片选拉高 HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET); return rxData; }

这里特别提醒一点：HAL 库的HAL_SPI_TransmitReceive默认第一个参数是发送缓冲区，第二个是接收缓冲区。如果你的数据是 8 位的，一定要确认传入的长度是字节数，而不是帧数。我见过不少人在这里把长度填成 1，结果只发了半个 16 位帧，从机完全没反应。另外 CS 拉高之前，最好加一个极短的__NOP()延时，保证最后一个字节确实完成移位，再释放片选。

3.4 软件片选 vs 硬件片选：这次我为什么坚持用 GPIO

前面提到了硬件 NSS 的弊端，这里用实际代码展示软件片选的做法。在 CubeMX 里，把 CS 对应的引脚配成 GPIO Output，初始电平设为 High（因为 CS 低有效）。发送时手动拉低，结束时拉高。

为什么不用硬件 NSS？我在调试中确实试过把 NSS 打开，结果是这样的：用逻辑分析仪抓 CS 信号，发现每传输完一个字节，CS 都会出现一次拉高的毛刺，对于 MT6835 这种严格依赖 CS 低电平维持整个寄存器访问周期的芯片来说，这就是“一帧被切成两半”，从机收到的地址和数据永远对不上。我也不知道是 STM32G031 的硬件 NSS 实现有特殊性，还是 MT6835 的片选时序太敏感，总之用软件片选后，毛刺消失，通信立刻稳定。

如果你非要用硬件 NSS，我建议你把 SPI 的帧格式配置成 16 位，让一次硬件片选内完成一个 16 位帧的发送，这样毛刺出现在帧边界，恰好符合 MT6835 的访问格式。但即便如此，我还是推荐软件片选，因为可控性实在好太多了，后续调试、扩展、多从机切换都方便。

4. 实战排查：三次“抓鬼”的全过程记录

这一节是整个项目里最跌宕起伏的部分。我在前面说过，SPI 波形看起来正常但通信就是不通。现在我把三次关键的排查过程完整写出来，包括我当时用的工具、观察到的现象、以及怎样一步步逼近真相。这对正在调试的读者会很有参考价值。

4.1 第一轮排查：上电读寄存器，返回值全 FF

一开始，我写了一个简单的测试函数：上电延时 100ms，然后读取 MT6835 的设备 ID 寄存器，期望读到某个固定值。结果显示0xFFFF，也就是 MISO 始终被拉高，没读到任何有效数据。我的第一反应是“从机没工作”，于是：

1. 测量 MT6835 供电引脚，电压正常，3.3V 稳定；
2. 测量功放芯片的 EN 引脚，确认它已经被拉高使能；
3. 用示波器量 MISO 引脚在通信期间的电平，发现它一直是高电平，没有任何翻转。

这个现象很奇怪，因为 MT6835 的 MISO 在有数据输出时应该会跳动。既然 MISO 不动，那只能说明：要么从机没收到主控发的地址（CS/SCK/MOSI 线路有问题），要么从机收到了但不知道你在跟它说话。于是我把注意力放到主控发送侧。

我用逻辑分析仪同时抓 SCK、MOSI、CS 三根线。观察到 MOSI 有正常的波形，数据看起来也像模像样；SCK 有正常的脉冲；CS 也能正确拉低。三根线都有信号，说明主控发送链路没问题。那一瞬间我真的有点崩溃：主控正常发，从机却不答，难道是芯片坏了？

然后我仔细数了一下 MOSI 上一个完整帧的 bit 数量。MT6835 是 16 位寄存器访问帧，我应该发送 16 个 bit，但逻辑分析仪上清晰地显示只抓到了 8 个 bit！问题找到了：CubeMX 默认识别我的数据宽度是 8 位，所以HAL_SPI_TransmitReceive发送时，把frame这个 16 位变量当成两字节是非问题，但实际上代码里frame是uint16_t，我强转成uint8_t *，传长度 2，应该没问题。可结果是只发了一字节。我检查代码后发现，问题出在(uint8_t *)&frame这个强转，在小端模式下，低字节在前，高字节在后，SPI 发送时先发了低字节。

如果 MT6835 期望高字节（寄存器地址）在前，那我就是先发了低字节（数据），从机把数据当成了地址，自然不回正确的响应。这个字节序问题在 SPI 里不常见，因为很多从机不在乎地址和数据的先后，但 MT6835 是严格的“高地址低数据”。解决方法是交换字节顺序，或者在构建frame时就使用联合体或手动字节拼接。我改成了：

uint8_t txBuf[2]; txBuf[0] = (regAddr & 0xFF); txBuf[1] = (data & 0xFF); HAL_SPI_TransmitReceive(&hspi1, txBuf, rxBuf, 2, 100);

这一改，MISO 立刻有反应了，虽然读回来的值还不是正确 ID，但至少从机开始应答。第一轮排查的最大收获：不要只看“有波形”，要数 bit、看字节序。

4.2 第二轮排查：读回来的寄存器值到底对不对

MISO 有反应之后，我信心满满地重新读 ID 寄存器，结果返回的依然不是手册里的值，而是 0x6A 之类完全不对的数据。这个现象说明，从机的 SPI 状态机已经开始工作，但由于某些原因，它把地址和数据之间的边界搞错了。

我用逻辑分析仪对比了 MT6835 手册里的时序图，发现一个细节：手册里在 CS 拉低之后，SCK 的第一个上升沿之前，有一段“地址建立时间”，并且 MOSI 上的地址位是从第 15 位开始的，即最高位先发。而代码里我用的HAL_SPI_TransmitReceive发送 16 位数据时，STM32 的硬件 SPI 在 8 位模式下，是先发txBuf[0]的低位还是高位？答案是：取决于 First Bit 配置。

我在 CubeMX 里把 First Bit 设成了 MSB First，理论上会先发最高位。但问题出在小端字节序和 16 位变量的组合上。我在第一次排查中已经把frame改成了字节数组，但地址字节和数据字节可能还是反的。于是我用逻辑分析仪完整解码一帧，显示 MOSI 上先出现的 8 位是数据而不是地址。翻代码，发现问题在：

txBuf[0] = regAddr; // 地址放前面 txBuf[1] = data; // 数据放后面

看着没错，但编译器警告我regAddr是 16 位，直接赋值给 8 位txBuf[0]时，高 8 位被丢掉了。而 MT6835 的寄存器地址并不都是 8 位的，有的寄存器地址字段是 8 位没问题，但某些扩展寄存器地址超过了 8 位范围，导致地址错乱。解决方法是严格控制regAddr的数据类型为uint8_t，避免截断。改成uint8_t regAddr8 = (uint8_t)(regAddr & 0xFF);后，再次读取，这次 ID 值正确了！

你可能觉得到这里就结束了，但实际上这轮排查让我意识到，SPI 调试不能只看波形，还要像做协议分析一样，逐 bit 去对比手册时序。逻辑分析仪在这里帮了大忙。没有它，光靠示波器一下一下数边沿，效率低太多。

4.3 第三轮排查：时钟极性和相位的“最后一根稻草”

ID 能读出来之后，我开始写配置寄存器，结果发现写入总是失败：写进去的值，重新读回来仍然和默认值一样，而且有时候会出现偶发的错误中断标志。这个现象非常典型：寄存器地址对了、数据也发了，但从机没有真正锁存，说明采样沿还是有问题。

我重新仔细阅读 MT6835 手册里的写时序图，发现一个容易忽略的小字备注：“Data is latched into the device on the rising edge of SCLK while CS is low。” 这句话本身符合 Mode 0，但进一步看，手册里的时序图在第一个上升沿之前，MOSI 上的数据其实已经提前稳定了。换句话说，从机实际上是在 SCLK 上升沿“之后”的那个时间段进行内部采样的，也就是更接近 Mode 1 的“second edge”特性。

为了验证这个猜想，我做了 AB 测试：把 CubeMX 里 CPOL 保持 Low，CPHA 改成 2 Edge（Mode 1），重新下载代码。结果非常明显：之前写入失败的寄存器，现在写入后立刻读回，值完全正确；之前偶发的中断标志也不再出现。随后我又测试了 Mode 0 和 Mode 3，确认在 Mode 0 下写入有一定概率成功但不稳定，Mode 1 下则是 100% 成功，50 次连续写入读回无一次错误。

这下真相大白：STM32G031 和 MT6835 之间真正匹配的其实是 Mode 1，而不是我看到手册第一眼以为的 Mode 0。原因在于 MT6835 的内部移位寄存器在 SCK 下降沿更新数据、上升沿采样，而 Mode 1 正好是“空闲低，第二个边沿（下降沿）更新、上升沿采样”。虽然从宏观上看，Mode 0 也能碰到上升沿，但由于建立/保持时间的微小差异，写入就变得不稳定。这个发现完美解释了之前所有“灵异现象”：为什么有时能读对 ID，有时配置不生效，数据总在变。

最后我在 CubeMX 里把 CPHA 设为 2 Edge，重新生成代码，整个系统稳定运行。从“见鬼”到“真相大白”，前后用了大概三个小时，但大部分时间都耗在 Mode 0 的死胡同里。改进后，我还把 SPI 时钟频率从 125kHz 逐步提高到 1MHz，实测依然稳定，说明 Mode 1 才是 MT6835 真正想要的时序。

5. 常见故障速查表与我的几点心得体会

把这次调试的经验沉淀成一份速查表，以后遇到类似的 MCU+SPI 从机配对问题，可以一张表快速定位。

这张表不只是理论，而是这次项目里真正遇到过的对话。特别想强调“第一次通信必失败”这一条，很多 MCU 在系统上电后会立刻执行初始化代码，此时外部芯片可能还在复位或者电源还没有稳定，SPI 首帧就容易被吞。解决方式很简单：在主函数里，初始化外设后，至少延时 10ms 再发起第一次 SPI 通信，或者先发送一个 dummy 字节唤醒从机，再进入正式通信流程。

5.1 调试工具的经验：逻辑分析仪比示波器更适合抓 SPI

这次排查让我对调试工具有了更深的体会。示波器适合看信号质量，比如边沿是否陡峭、过冲是否严重、时序间距是否足够，但在协议分析上，逻辑分析仪远胜一筹。SPI 是典型的数字协议，你不需要知道每个边沿多快，你需要知道的是“哪个边沿采样”“先收到的是哪几位”。逻辑分析仪可以解码成 16 进制格式，直接对比发送帧和期望帧，效率高得不是一点半点。

如果你手里只有示波器，也能调，但比较费眼神：需要把 SCK 和 MOSI 同时显示，用光标测量每个 bit 的电平，心里默写二进制再转十六进制。这样也能定位字节序错误或 CPOL/CPHA 不匹配，但耗时至少翻倍。所以我建议嵌入式调试常用工具里，除了万用表和示波器，强烈建议添置一个便宜的逻辑分析仪，几十块钱就能买到 8 通道 24MHz 采样率的，对 SPI/IIC/UART 这种慢速协议足够用了。

5.2 手册阅读：不要只看文字，要看时序图的“眉角”

这次最大的教训，是数据手册的正文描述和时序图之间可能有细微差别。MT6835 的正文里写“Data is latched on the rising edge”，听起来像 Mode 0，但实际因为内部电路的保持时间要求，用 Mode 1 更稳定。这种差异并不罕见，尤其是低成本 IC，设计时可能根本没有严格按 SPI 标准的 CPOL/CPHA 定义去做。

我的建议是：对于任何一颗新接触的 SPI 从机芯片，你拿到手册后，直接找它的 SPI 时序图，然后把 SCK、MOSI、MISO 三根线的波形画出来，对照标准的四种模式图去匹配，不要只看文字描述。如果手册连时序图都没有，就用“穷举法”：把四种模式都跑一遍，每次用一个固定寄存器做写后读测试，记录哪个模式稳定。这个方法的成本很低，但能从根本上排除时序不匹配的嫌疑，比盲猜快得多。

5.3 一个小技巧：先用慢时钟和写后读验证你的 SPI 对不对

很多人一开始配 SPI 就直接上能支持的最高频率，比如 8MHz、16MHz，结果一旦通信不通，很难判断是时序模式问题还是信号完整性差问题。我的习惯是：先用最低分频，开启写后读模式，把一个寄存器的值写成 0xA5，再读回来，对比是否一致。这个测试如果能通过，再逐步提高频率。如果 125kHz 下写后读都不稳定，那基本可以断定是 CPOL/CPHA 或字节序问题，不需要犹豫，直接去改配置。

注意写后读测试时，最好选一个可读可写且默认值有意义的寄存器，比如设备 ID 或控制寄存器。如果选一个只读寄存器，那写进去的值永远不会回来，会造成误判。另外，测试代码里最好加一个错误计数，连续读写 100 次，统计错误次数，而不是只测一次。一次成功有可能是运气，连续 100 次稳定才算真的稳。

调试这种事，踩坑不可怕，可怕的是不知道怎么一步一步逼近真相。我这次和 MT6835 的第一次 SPI 通信，前前后后换过芯片、改过代码、查过电源，最后发现只是一个小小的时钟相位问题。所以如果你也遇到了类似的“灵异事件”，不妨从最简单的四件事查起：引脚复用有没有配错、字节序是不是反了、CPOL/CPHA 到底对不对、片选时序是否被硬件 NSS 干扰。把这张速查表贴在工位上，说不定能帮你省下好几个小时的挠头时间。