【金山文档 | WPS云文档】 新建 DOC 文档
https://www.kdocs.cn/l/cjaqKjk2mVFu
这是S32DS的debug日志
1.LED被我拆了，R7电压测不了，转而测了R8对地电压为3.08V
2.根据昨天的解答进行新一轮的试验后GPT给出的答复：
写入会话内（多区域验证）: 20007000 00000411 … 
数据真实存在复位后
（同一会话）: 20007000 00000411 … 数据还在
断电/断开后重连: FFFFFFFF FFFFFFFF … 
全空
程序能写进去、能立即读回、能撑过复位——但只要一断电就全丢
会不会是boot模式设置问题？
stm32其中有一个boot模式是烧录到内存里，断电就丢失，不知道你这s32是不是也有这设置
把流程仔细重跑一遍后GPT的新结论：关键数据对比
| 时刻 | 0x2400 区域 | 0x0 区域 |
|---|---|---|
| 写入后立即 | 00800040 48484848 |
20007000 00000411 |
| 同一会话 30 秒后 | 00800040 48484848 还在！ |
Could not read memory（已失效） |
| 退出重连后（1-2 分钟） | FF（全部丢失） | FF |
真相浮出水面：flash 电荷在分钟级快速泄漏！
- 写入瞬间：电荷充足 → 数据完好
- 30 秒：低地址区（0x0）先失效，高地址区（0x2400）勉强还在
- 1-2 分钟后：全部归 FF
这就是GPT最终给的定论了
芯片 flash 存储单元物理失效（电荷分钟级泄漏）★真正的病根
│
▼
程序永远存不住 → flash 长期处于空/失效状态
│
▼
空 flash → CPU 取 0xFFFFFFFE → 总线错误 → HardFault 递归 → LOCKUP ★真实
│
▼
LOCKUP 610μs 复位循环（示波器锯齿波 1.64kHz）★真实，你仿真都复现了
│
▼
调试器 halt 失败 → RAMCode 被打断 → 烧录报错（-1/-5）★真实
│
▼
偶发写入成功（电荷暂时足）→ 立即读正常 → 1-2 分钟后泄漏归 FF ★真实
这问题是真的少见，换块板试试
就是因为手头没有多余板子，才一直折腾这块，等后面新的板子到了就知道是不是芯片问题了。
找到问题了吗
新板子没到，暂时还是flash坏了的可能性最大