话说这玩意儿到底能怎么“见鬼”？板子从F103换成G031之后，第一版程序烧进去，屏亮了，但亮得完全不对——花屏、错位、颜色随机。换回F103上同样的逻辑，一切正常；换到G031，故障复现率能到七八成。示波器和逻辑分析仪都上了，SCK和MOSI的波形跟模组规格书里的时序图画得一模一样，可屏就是不给面子。前前后后查了两天半，最后发现问题根本不是SPI协议本身，而是卡在“SPI发完了”和“锁存数据”这两个动作之间的那点时间缝隙里。这篇文章把这个过程原原本本捋一遍，给后面要在STM32G031上驱动MT6835这类SPI-like点屏IC的朋友做个参考。
这片子其实是块LED透明屏模组，驱动IC用的MT6835，接口看着像SPI，实际是个纯移位寄存器加锁存器的串行驱动方案。或者说，它只是“长得像SPI”，内部根本没有SPI从机的寄存器组、地址和片选逻辑。搞清楚这一点，后面排查“见鬼”现象的路子就清晰很多。
1. 板子、屏与“见鬼”现场：先说清楚我在调什么
1.1 MT6835是什么，它和标准SPI外设的“貌合神离”
MT6835是LED显示驱动IC里比较常见的一颗，常用于透明屏、点阵屏这类需要高灰度、多通道恒流驱动的场景。它内部实质是一个16通道恒流输出控制器，每个通道支持16bit PWM灰度。模组上每个像素由RGB三颗LED组成，所以驱动一个完整像素需要向IC写R、G、B各16bit数据，一共48bit。
接口上，我拿到的模组是四线制：SDI（串行数据输入）、SCK（移位时钟）、LAT（锁存信号）、OE（输出使能），VCC和GND供电。这里没有MISO，所以从严格意义上讲它并不是标准的四线SPI，更像是“三线SPI-like”：SCK提供移位时钟、SDI按位移入数据、LAT负责把移位寄存器里的数据一次性锁存到输出端，OE控制整屏的显示使能。
一定要理解的是：MT6835对“SPI协议”的理解只有两点——时钟边沿和位数量。它不关心字节边界，不关心片选信号，不关心你用的是SPI外设还是GPIO模拟的时序，只要SCK上给出足够数量的边沿，SDI上的数据按顺序被移进内部移位寄存器就行。标准SPI主机的片选（NSS/CS）概念在这里根本不存在，所以CubeMX里配置的硬件片选、软件片选对这个芯片都没有实际意义。
1.2 硬件连接与初始代码：看起来没有任何问题
板子是一块STM32G031最小系统板，主频64MHz。屏模组引脚直接飞线接到SPI1外设：
| 功能 | MCU引脚 | 模组引脚 |
|---|---|---|
| SPI1_SCK | PA5 | SCK |
| SPI1_MOSI | PA7 | SDI |
| GPIO输出 | PA6 | LAT |
| GPIO输出 | PA4 | OE |
供电用的是板载3.3V，模组额定工作电压3.3V～5V，电流不大，稳压器余量足够。
CubeMX里的SPI1配置如下：
- 工作模式：Full-Duplex Master（实际上只用到TX）
- 数据大小：8bit
- 时钟极性CPOL：Low
- 时钟相位CPHA：1 Edge（第一沿采样）
- 波特率分频：16分频，SPI时钟约4MHz
- 帧格式：MSB First
- 片选方式：软件片选（Soft NSS）
然后主循环里做的事情用伪码描述就是：
uint8_t frame[6]; // 一个像素RGB各16bit，共48bit = 6字节 frame[0] = r_h; frame[1] = r_l; frame[2] = g_h; frame[3] = g_l; frame[4] = b_h; frame[5] = b_l; HAL_GPIO_WritePin(OE_GPIO_Port, OE_Pin, GPIO_PIN_RESET); // 使能输出 HAL_SPI_Transmit(&hspi1, frame, 6, 100); // 发6字节 HAL_GPIO_WritePin(LAT_GPIO_Port, LAT_Pin, GPIO_PIN_SET); // 锁存 HAL_GPIO_WritePin(LAT_GPIO_Port, LAT_Pin, GPIO_PIN_RESET); // 释放锁存这段代码写得没毛病，F103上就是这么跑的。但换到G031上，屏幕显示随机花屏、颜色错位，偶尔整个画面偏移一个像素，重启后现象还随机变化。这才叫“见鬼”——代码一模一样，换了颗MCU就翻车，而且不是必现，是概率性偶发。
2. 第一轮排查：供电、接线、逻辑分析仪三件套
2.1 先排除最朴素的故障：供电与接线
遇到“换一颗MCU就翻车”的情况，我第一反应不是查协议，而是查物理层。毕竟G031是低功耗系列的芯片，IO驱动能力、引脚映射和F103不完全一样，万一是PA5/PA7复用没配好、GPIO速度不对或者屏模块电流把3.3V拉垮了呢。
先量了模组供电引脚，3.32V，纹波不到30mV，电压非常稳。再检查SCK和SDI的引脚电平，空闲时都是低电平，没有看到悬空浮动的迹象。然后把跳线重新焊了一遍，缩短了飞线长度，问题依旧。
这里提醒一句：排查SPI类点屏时序问题，示波器（至少逻辑分析仪）必须上。肉眼看不出毛刺，但波形能告诉你真相。我用的逻辑分析仪采样率是500MHz，带宽足够看到4MHz SCK上的细节。抓完发现，SCK和MOSI（SDI）的波形一开始看“真是干净”：时钟方波完整，数据位和SCK沿的对应关系也是对的，帧长6字节正好对应48bit。
2.2 逻辑分析仪看波形：SCK和MOSI在宏观上完全正确
把抓到的波形放大，对照MT6835规格书里的时序图，逐项核对：
- SCK空闲电平：低，匹配CPOL=Low。
- SDI数据在SCK第一沿（上升沿）被采样，匹配CPHA=1Edge。
- 一帧数据6字节，MSB在前，bit数量和顺序完全对。
- 帧与帧之间SCK停顿正常，没有多余时钟。
按说这种波形喂给任何一个标准SPI从机，都不可能出错。可MT6835就是显示出花屏，这就很反常识。
为了确认屏本身没坏，我把模组接到另一块Arduino上用软件模拟SPI驱动，结果一次点亮，显示完全正常。这个实验结果非常关键：屏是好的，剩下的嫌疑就是G031的硬件SPI外设、软件配置，或者两者结合后产生的某种“规格书里没画清楚”的时序细节。
3. 交叉验证：IO模拟SPI一把过，硬件SPI就是不行
3.1 用IO模拟SPI验证屏没有坏
台式机上写了一段最简单的GPIO模拟SPI程序来驱动这个模组，逻辑如下：
void mt6835_write_bit(uint8_t bit) { HAL_GPIO_WritePin(SDI_GPIO_Port, SDI_Pin, bit ? GPIO_PIN_SET : GPIO_PIN_RESET); HAL_GPIO_WritePin(SCK_GPIO_Port, SCK_Pin, GPIO_PIN_SET); delay_ns(120); // 数据建立时间 HAL_GPIO_WritePin(SCK_GPIO_Port, SCK_Pin, GPIO_PIN_RESET); delay_ns(120); // 时钟低电平保持时间 } void mt6835_send_frame(uint16_t r, uint16_t g, uint16_t b) { for (int i = 15; i >= 0; i--) mt6835_write_bit((r >> i) & 1); for (int i = 15; i >= 0; i--) mt6835_write_bit((g >> i) & 1); for (int i = 15; i >= 0; i--) mt6835_write_bit((b >> i) & 1); delay_ns(100); // 等待最后一位数据稳定 LAT_SET_HIGH(); delay_ns(500); // 锁存脉冲宽度 LAT_SET_LOW(); }这段代码烧进G031，屏正常显示。没有花屏，没有错位，颜色完全正确。
由此可以得到两个结论：
- 硬件SPI和GPIO模拟SPI在波形上几乎一致，但显示结果一个错一个对，说明问题出在某个“逻辑分析仪上看不出来”的电气或时序层面。
- 既然GPIO模拟的SCK频率大约不到1MHz都能正常点亮，说明屏对SCK速率没有苛刻要求，排除了“G031 SPI外设频率过高导致信号质量差”这一类怀疑方向。
3.2 对比两种实现，差异点浮出水面
接下来我把硬件SPI发送结束后、拉LAT上升沿这个关键时间点用示波器仔细抠了一遍。重点观察两处：
- HAL_SPI_Transmit()函数返回时，SPI外设是否真的把所有数据都送完了？
- 拉LAT的上升沿，落在SCK最后一个下降沿之后多久？
对比GPIO模拟的那段代码，里面每发完一个bit都会等120ns，发完整帧还会额外再等100ns才拉LAT，所以LAT上升沿离最后一位SCK下降沿至少有220ns以上的间隔，MT6835完全有时间把最后一位数据稳定锁存。
而硬件SPI这边，HAL_SPI_Transmit()返回后我立刻拉LAT，中间没有任何等待。问题就藏在这里。
4. 真凶：不是相位极性，而是“最后半拍”和MOSI电平
4.1 HAL_SPI_Transmit的返回陷阱：BSY标志与最后一拍
很多人在STM32上用HAL库的HAL_SPI_Transmit()时，都默认这个函数返回就意味着“数据已经从MOSI引脚发出去了”。严格来说，这个理解在绝大多数场景下没啥问题，因为SPI发送数据时，数据从移位寄存器串行移出，最后一个bit在SCK最后一个边沿之后还会继续在MOSI上保持一段时间。HAL库在发送完最后一个字节后检查TXE标志（发送数据寄存器空）便会准备返回，而不会等待移位寄存器完全把最后一位推出、SCK完全回到空闲状态。
等到主程序执行到下一行代码去拉LAT时，如果这段代码在时间上恰好和“最后一个数据位在MOSI上还不稳定”的窗口重叠，MT6835内部移位寄存器的最后一级就可能锁存到错误的电平。别小看这一个bit的错误——整帧数据从最高位开始移位，最后一位出错等效于整个48bit数据内容整体偏移了一个bit，显示到屏上就是花屏、像素错位、颜色随机，正是我遇到的现象。
4.2 波形实锤：LAT上升沿刚好砸在数据不确定窗口上
用示波器同时抓SCK、MOSI和LAT三个信号，单次触发抓HAL_SPI_Transmit返回后拉LAT的那一段，真相一目了然：
![真实波形示意：LAT上升沿落在数据跳变窗口内]
准确说，当时量到的时序是：SCK最后一个下降沿到LAT上升沿之间只有大约十几纳秒，而MOSI上最后一位数据的电平翻转点恰好也在这一小段窗口里。MT6835的数据建立时间即便不严格，也不可能在十几纳秒内完成稳定的输入锁存。GPIO模拟版本因为有显式延时，LAT上升沿离最后一位数据稳定点超过200ns，所以一直正常。
有意思的是，这个问题和CPOL/CPHA配置关系不大。我把SPI的四种极性/相位组合都试过，现象基本一致，只是错乱程度略有区别。原因是锁存窗口的问题根子上不在“用哪个沿采样”，而在“最后一位数据有没有被稳定地送进芯片并保持住”，标准SPI从机有片选和寄存器缓冲可以容忍这类毛刺，但MT6835这种纯移位寄存器型芯片对锁存时刻的输入电平要求非常硬核。
4.3 GPIO驱动速度的次生问题
除了锁存时序，还有一个“帮凶”是G031的GPIO输出速度配置。CubeMX默认生成工程里，SPI1的SCK和MOSI引脚如果被设为Low Speed，GPIO输出级的压摆率会偏慢。4MHz时钟下，每个bit只有250ns宽度，如果MOSI上升沿就要花掉几十ns，留给数据稳定的窗口会进一步被压缩。确实我后来把PA5、PA7的GPIO Speed改成Very High之后，再用示波器看，边沿变得利索很多，花屏概率也从七八成降到了偶尔复发，不过只要LAT时序问题不解决，它还是会偶发。
这里也说清楚：GPIO Speed不是根因，但它是压垮骆驼的最后一根稻草，协同放大了LAT时序缺陷。
5. 修复与预防：一次SPI“误解”换来的排查清单
5.1 最终修复：三条改动，稳定复现彻底消失
修复方案其实不复杂，三条：
第一，发送完SPI数据后，等待SPI外设BSY标志位清零，再拉高LAT。修改后的代码段：
HAL_SPI_Transmit(&hspi1, (uint8_t*)frame, 6, 10); // 关键：等待移位寄存器把最后一位彻底推出去，SCK回到空闲 while (hspi1.Instance->SR & SPI_SR_BSY); // 再给一点余量，保证MT6835的输入建立时间 delay_us(1); LAT_SET_HIGH(); delay_us(1); LAT_SET_LOW();SPI_SR_BSY是SPI状态寄存器里的忙标志，它清零代表当前没有数据在传输。虽然HAL库函数名面上是“Transmit完成”，但只有BSY清零才是物理意义上的“最后一个bit已经在MOSI上稳定保持”。
第二，把CubeMX里PA5（SCK）和PA7（MOSI）的GPIO输出速度从Low改为Very High。
第三，如果项目对刷新率要求不高，可以把SPI时钟从4MHz降到2MHz或1MHz，给数据建立时间留更多余量。降频不是必须的，但能显著提高抗干扰和兼容性，特别是飞线比较长的场景。
修复后测试：连续跑了一整晚的滚动色块、跳变图形测试程序，故障零复现。同样的代码烧进三块G031板子，全部稳定。
5.2 复盘：遇到SPI驱动点屏花屏，按什么顺序查
这个问题解决之后，我把整个排查过程整理成了一份清单，后面踩同类坑时直接按这个顺序走：
- 先确认供电和接线，排除低端物理问题。
- 用逻辑分析仪抓波形，核对CPOL/CPHA、MSB/LSB、位数量、帧长度，排除标准SPI配置问题。
- 如果波形看上去全对但屏还是花，立刻用GPIO模拟SPI写一个最小驱动交叉验证。这一步能把“屏坏”“硬件SPI有问题”“时序细节有问题”三个方向快速劈开。
- 硬件SPI发送后，务必等待BSY清零，再操作LAT/LE这类锁存信号。凡是遇到移位寄存器型串行驱动IC，这条规矩必须刻进脑子里。
- GPIO输出速度按实际SPI时钟调高，不要迷信CubeMX默认配置。
- 遇到连续字节之间MOSI电平翻转时，确认翻转瞬间不会和锁存沿短接。如果LAT由外部逻辑控制，建议给LAT做一个最小延时，宁多勿少。
这几年调试各种屏、传感器、Flash芯片，最深刻的体会是：SPI这个协议名字听起来统一，但每一颗芯片对时序细节的容忍度天差地别。标准SPI从机内部有完整的采样对齐和缓冲机制，很多坑都被消化在芯片内部了；而MT6835这类“SPI-like”的驱动IC，本质上就是一堆移位寄存器加锁存器，它对时序的要求接近“裸金属”——每一拍都得实打实落在稳定的区间里，没有芯片帮你兜底。这次“见鬼”的调试经历，说到底是我对HAL库“发送完成”这件事的理解不够严谨造成的。以后但凡遇到逻辑分析仪说“波形全对”但设备死活不工作的情况，我都会先问一句：信号是送到了，但真的“稳定送到”了吗？
