[Kingsoft Docs | WPS Cloud Docs] New DOC document
https://www.kdocs.cn/l/cjaqKjk2mVFu
These are the S32DS debug logs
- I removed the LED, so I couldn’t measure the voltage across R7. Instead, I measured the voltage from R8 to ground, which was 3.08 V.
- After a new round of testing based on yesterday’s answer, GPT responded:
Writing within the session (multi-area verification): 20007000 00000411 …
Data truly exists after reset
(same session): 20007000 00000411 … Data is still there
After power loss/disconnection and reconnect: FFFFFFFF FFFFFFFF …
All empty
The program can write to it, read it back immediately, and survive a reset—but as soon as power is lost, everything is gone.
Could it be a boot mode setting issue?
One of the STM32 boot modes is programmed into memory and is lost when power is removed. I’m not sure whether your S32 has a similar setting.
After carefully rerunning the process, GPT’s new conclusion: Key Data Comparison
| Time | 0x2400 Area | 0x0 Area |
|---|---|---|
| Immediately after writing | 00800040 48484848 |
20007000 00000411 |
| 30 seconds later in the same session | 00800040 48484848 Still there! |
Could not read memory (invalidated) |
| After exiting and reconnecting (1–2 minutes) | FF (all lost) | FF |
The truth is coming to light: the flash charge is leaking rapidly on a minute-level timescale!
- At the moment of writing: charge is sufficient → data remains intact
- After 30 seconds: the low-address area (0x0) fails first, while the high-address area (0x2400) barely remains
- After 1–2 minutes: everything reverts to FF
This is the final conclusion GPT ultimately gave.
Chip flash memory cell physical failure (charge leakage on the minute scale) ★ the real root cause
│
▼
The program can never be stored → the flash remains empty/failed for a long time
│
▼
Empty flash → CPU fetches 0xFFFFFFFE → bus error → recursive HardFault → LOCKUP ★ real
│
▼
Debugger halt fails → RAMCode is interrupted → flashing error (-1/-5) ★ real
│
▼
Occasional write succeeds (charge is temporarily sufficient) → immediate read is normal → leaks back to FF after 1–2 minutes ★ real
This issue is genuinely rare—try swapping in another board.
It’s precisely because I don’t have any spare boards on hand that I’ve been fiddling with this one this whole time. Once the new boards arrive later, we’ll know whether it’s a chip issue.