上周调试看门狗好不好使，结果卡在了第一步，spi不通。打了下断点，发现 spi 读取pmic 芯片的device id 有问题，上层的接收buf
```
RX 前两个字节正常
第三个字节固定是 0x00
```
我没调试过PMIC芯片，这个手写模块上个版本已经测过是没问题，spi也确定是没问题，最痛苦的地方是我不会用示波器，板子也很糙，无从下手
硬着头皮问ai搜教程，用示波器看波形。搞了半天，`CLK`、`MOSI`、`CS` 几根线倒是都测到过了，时序看起来也没什么明显异常。比较麻烦的是 `MISO` 没有方便的 TP 点，不太好直接测
硬件我经验少，看不出明显问题，先回到配置上排查。
我先重新同步了一遍最新版 EB 工程里的 SPI 和 Port 配置，然后拿之前确认好用的老版本做对比，还有一个不知道咋改：
```
旧版本 SPI 外设时钟：100 MHz
新版本 SPI 外设时钟：200 MHz
```
对应的 baudrate prescaler 也从：
```
0x31 → 0x63
```
但是算了下，理论上实际 SPI SCLK 还是保持在 2 MHz，然后开始怀疑

>外设时钟从 100 MHz 变成 200 MHz 以后，一些以 VCLK 为基准的 SPI delay 会不会跟着变短了？

继续翻 LP8774x 的手册，看到 SPI timing 里有一项：
```
CS 拉低 → 第一个 SCLK
至少 150 ns
```
这时候就有点像
即使 SCLK 还是 2 MHz，AWR2E44 内部的一些 delay 是按照 100 MHz / 200 MHz 的 VCLK tick 来算的。VCLK 翻倍以后，一个 tick 从 10 ns 变成 5 ns，如果 delay 配置没跟着调整，实际等待时间就可能缩短。
所以先沿着这个方向试了一把，把：
```
.Spi_ClkDelays = {0xFFFFU, 0x0000U}
```
改成：
```
.Spi_ClkDelays = {0xFFFFU, 0x2000U}
```
想把 `C2TDELAY` 拉长，保证 CS 到第一个 Clock 的时间足够。
结果没用。
```
Mode 0
第三个 RX byte 仍然是 0x00
```
这一步虽然没解决问题，但也算排掉了一个比较大的嫌疑：至少这个现象不是单纯靠加大 CS-to-CLK delay 就能解决的。
接着才开始看 SPI Mode。
原来的 EB 配置一直是：
```
Mode 0
```
我试着改成：
```
Mode 1
```
结果就很神奇：
```
三个字节全部正常
```
事情旧更奇怪了。因为看了下芯片手册的 SPI timing diagram：
```
SCLK 空闲低
上升沿采样
下降沿切换数据
```
从标准 SPI 的定义来看，怎么看都更像 Mode 0。这就挺离谱，很别扭
```
PMIC 手册看着要求 Mode0

旧版本：
EB Mode0 → 正常

新版本：
EB Mode0 → 异常

新版本：
EB Mode1 → 正常
```
到这里再继续看 EB 配置已经没什么意义了，只能继续往驱动底层去看
然后终于发现了问题，旧版本虽然 EB 里配置的是：
```
Mode0
```
生成代码里也确实是：
```
Spi_Mode = 0
```
但驱动层并不是直接把这个 `0` 写进 MibSPI 的 `PHASE`。
中间还有一层转换：
```
0 → 1
```
旧版本实际链路是：

```
EB Mode0
→ generated Spi_Mode = 0
→ driver 做一次转换
→ PHASE = 1
→ 正常
```
而新版本里这层转换没了：
```
EB Mode0
→ generated Spi_Mode = 0
→ 直接写入
→ PHASE = 0
→ 第三个字节 = 0x00
```
我当时也一阵无语，不知道这破驱动咋写的
```
EB Mode1
→ generated Spi_Mode = 1
→ 直接写入
→ PHASE = 1
→ 正常
```

```
PHASE = 1  → 正常
PHASE = 0  → 异常
```
EB 中配置的mode 0和mode 1就恶心
这个问题最坑的地方就是：
>**表面上看，新旧两个版本 EB 都配置了 Mode0；但一路走到硬件寄存器，实际配置已经不是同一个东西了。**

最终关系其实是：
```
旧版本：
EB Mode0
→ generated 0
→ driver 转换
→ PHASE=1
→ OK

新版本：
EB Mode0
→ generated 0
→ 直接写
→ PHASE=0
→ NG

新版本改 Mode1：
EB Mode1
→ generated 1
→ 直接写
→ PHASE=1
→ OK
```
**遇到 MCAL 升级后的外设问题，不能只对比 EB 工程，也不能只看 generated code。**

可能还得一路追到底，实际的去看驱动代码

```
EB 配置
↓
生成配置
↓
驱动层处理
↓
最终硬件寄存器
```
不过这次最大的收获应该是能简单用下示波器了～

上周调试看门狗好不好使，结果卡在了第一步，spi不通。打了下断点，发现 spi 读取pmic 芯片的device id 有问题，上层的接收buf

无语的mcal驱动，spi模式反着写

调试看门狗时发现 SPI 读取 LP8774x Device ID 的第三字节固定为 0。排查波形、时钟和 delay 均无效，直到 Mode1 恢复正常。继续追到 MCAL 驱动，最终发现新旧版本对 `Spi_Mode` 到 MibSPI `PHASE` 的映射不同。教训：MCAL 升级后，不能只看 EB 和生成代码，还要追到底层寄存器。

其他

排查PMIC SPI读取异常，问题根源是MCAL升级后驱动层对SPI相位转换逻辑丢失。旧版本EB Mode0经转换写入PHASE=1正常，新版本直接写入PHASE=0导致第三字节固定0x00。改用Mode1后正常，需深入驱动代码确认寄存器实际配置，不能仅依赖EB配置对比。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

无语的mcal驱动，spi模式反着写-腾讯云开发者社区-腾讯云

无语的mcal驱动，spi模式反着写

无语的mcal驱动，spi模式反着写

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐