关于昨天的S32K144复位引脚问题后续

技术讨论 嵌入式系统 / Embedded Systems
,
1

【金山文档 | WPS云文档】 新建 DOC 文档

https://www.kdocs.cn/l/cjaqKjk2mVFu

这是S32DS的debug日志

2

1.LED被我拆了，R7电压测不了，转而测了R8对地电压为3.08V
2.根据昨天的解答进行新一轮的试验后GPT给出的答复：
写入会话内（多区域验证）: 20007000 00000411 … :white_check_mark: 数据真实存在复位后
（同一会话）: 20007000 00000411 … :white_check_mark: 数据还在
断电/断开后重连: FFFFFFFF FFFFFFFF … :cross_mark: 全空

程序能写进去、能立即读回、能撑过复位——但只要一断电就全丢

3

会不会是boot模式设置问题？
stm32其中有一个boot模式是烧录到内存里，断电就丢失，不知道你这s32是不是也有这设置

4

把流程仔细重跑一遍后GPT的新结论：关键数据对比

时刻 0x2400 区域 0x0 区域
写入后立即 00800040 48484848 :white_check_mark: 20007000 00000411 :white_check_mark:
同一会话 30 秒后 00800040 48484848 :white_check_mark: 还在！ Could not read memory（已失效）
退出重连后（1-2 分钟） FF（全部丢失） FF

真相浮出水面：flash 电荷在分钟级快速泄漏！

  • 写入瞬间：电荷充足 → 数据完好
  • 30 秒：低地址区（0x0）先失效，高地址区（0x2400）勉强还在
  • 1-2 分钟后：全部归 FF
5

这就是GPT最终给的定论了

芯片 flash 存储单元物理失效（电荷分钟级泄漏）★真正的病根
│
▼
程序永远存不住 → flash 长期处于空/失效状态
│
▼
空 flash → CPU 取 0xFFFFFFFE → 总线错误 → HardFault 递归 → LOCKUP ★真实
│
▼
LOCKUP 610μs 复位循环（示波器锯齿波 1.64kHz）★真实，你仿真都复现了
│
▼
调试器 halt 失败 → RAMCode 被打断 → 烧录报错（-1/-5）★真实
│
▼
偶发写入成功（电荷暂时足）→ 立即读正常 → 1-2 分钟后泄漏归 FF ★真实

6

这问题是真的少见，换块板试试

7

就是因为手头没有多余板子，才一直折腾这块，等后面新的板子到了就知道是不是芯片问题了。

8

找到问题了吗

9

新板子没到，暂时还是flash坏了的可能性最大