Fix GET_PART_INFO/GET_SYS_STATE/GET_FUNC_INFO byte offsets; confirm Si4684 blobs genuine
Si4684Driver::getPartInfo()/getSysState() existed but were never called, so their byte-offset bugs never surfaced. Wired them into a boot-time diagnostic log (part number, firmware revision, active image, streamed blob byte counts) to check whether the loaded DAB/FM firmware images are genuine and intact, as an alternative explanation to the QFN exposed-pad hardware hypothesis. Fixed two rounds of off-by-one bugs found while doing this: the fields were initially read one byte too far right (e.g. firmwareBuild was reading a flag byte, not a version number); the first fix undershot in the other direction by not accounting for readRaw()'s one-byte SPI lead-in before STATUS0 (already documented and confirmed elsewhere in this file, in pollStc()) -- caught because the "fixed" GET_SYS_STATE reported image=192 (0xC0), the exact signature of STATUS3 with PUP_STATE=3 seen throughout this investigation. All three response buffers were already sized for the lead-in byte, which confirmed the correct fix. Verdict, captured live: blob streamed bytes match local file sizes exactly (no truncation), GET_SYS_STATE reports image=2 (DAB active, correct), GET_PART_INFO reports part=4684 (matches expected Si4684 part number) with a plausible firmware revision -- the loaded DAB firmware is genuine and intact. This closes the last plausible firmware-side explanation for the FM/DAB no-lock symptom; docs/si4684-rf-investigation-report.md and docs/TODO.md (P4/H5) updated with the full record and verdict. Also noted, not yet fixed: BT1035 AT-init now fails deterministically on every boot (was a one-off earlier this session) -- see report's Open Items. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Claude Sonnet 5
@@ -62,6 +62,11 @@ verify ADAU replay after reboot.
|
||||
After H1 passes, trial build with `sdkconfig.defaults.production` overlay on
|
||||
a sacrificial unit; confirm RELEASE mode policy before shipping.
|
||||
|
||||
### H5. Si4684 FM/DAB no-lock — blob integrity checked, verdict: hardware
|
||||
**Verdict (2026-08-13): blob OK → suspect U6 RF ground (re-open PCBWay)**, not
|
||||
a firmware/blob defect. Full investigation, evidence, and the two byte-offset
|
||||
bugs found/fixed while verifying this: [`docs/si4684-rf-investigation-report.md`](si4684-rf-investigation-report.md).
|
||||
|
||||
---
|
||||
|
||||
## Open firmware polish (non-blocking)
|
||||
|
||||
@@ -111,6 +111,50 @@ across streaming config, beep toggles, Wi-Fi, and station data). **Not yet
|
||||
confirmed with the actual error code — re-run the diagnostic build and capture
|
||||
the log line to close this out.**
|
||||
|
||||
## Blob/firmware-image integrity check (completed, negative — blobs are genuine)
|
||||
|
||||
`getPartInfo()` and `getSysState()` (`components/drivers/si4684/src/Si4684Driver.cpp`)
|
||||
already existed to decode `GET_PART_INFO`/`GET_FUNC_INFO`/`GET_SYS_STATE`, but were
|
||||
never called anywhere in the codebase — dead code, so their byte-offset bugs had
|
||||
never surfaced. Found and fixed **two rounds** of off-by-one bugs while wiring them
|
||||
into a boot-time diagnostic log:
|
||||
|
||||
1. First pass: every field (chip ID, firmware major/minor/build, image type) read
|
||||
one byte too far right — e.g. `firmwareBuild` was actually reading the
|
||||
NOSVN/LOCATION flag byte, not a version number.
|
||||
2. That "fix" was itself wrong in the other direction. `readRaw()` responses carry
|
||||
a one-byte SPI lead-in before STATUS0 — the same convention already confirmed
|
||||
and commented in `pollStc()` elsewhere in this file — which the first pass
|
||||
didn't account for. Caught empirically: the "fixed" `GET_SYS_STATE` reported
|
||||
`image=192` (`0xC0`), the exact byte pattern of STATUS3 with `PUP_STATE=3`
|
||||
seen dozens of times elsewhere in this investigation — proof the read was
|
||||
still one byte off, in the other direction. All three existing response
|
||||
buffer sizes (7/13/24 bytes) already matched "N response bytes + 1 lead-in",
|
||||
confirming the lead-in-byte offset (not the no-lead-in offset) is correct.
|
||||
|
||||
**Result after the fix**, captured live from the device (DAB boots first at
|
||||
startup):
|
||||
|
||||
```
|
||||
Si4684: blob streamed: 5796/5796 bytes (rom_patch_016.bin, matches file size exactly)
|
||||
Si4684: blob streamed: 517524/517524 bytes (dab_firmware.bin, matches file size exactly)
|
||||
Si4684: GET_SYS_STATE: image=2 (2 = DAB active, correct per AN649)
|
||||
Si4684: GET_PART_INFO/GET_FUNC_INFO: part=4684 rev=4.0.5 svnid=0x00001754
|
||||
```
|
||||
|
||||
`part=4684` matches the expected Si4684 part number exactly; `rev=4.0.5` and the
|
||||
SVN ID are plausible, sane values, not garbage. Blob byte counts streamed over
|
||||
SPI match the local file sizes exactly — no truncation in transit. **Verdict:
|
||||
the DAB blob loaded on the chip is genuine and intact.** (FM boot's GET_FUNC_INFO
|
||||
was not yet captured — a BT1035 AT-init failure, see below, has been blocking the
|
||||
device from reaching the point in the boot sequence where FM is exercised. Not
|
||||
expected to change this verdict; DAB alone already answers the blob-integrity
|
||||
question this check was for.)
|
||||
|
||||
This closes the last plausible firmware-side explanation for the no-lock symptom.
|
||||
Combined with everything else in this report, the QFN exposed-pad hardware
|
||||
hypothesis is now the leading and best-supported explanation.
|
||||
|
||||
## Open items
|
||||
|
||||
1. Confirm the exact NVS error code for the audio-profile save failure and fix
|
||||
@@ -121,7 +165,10 @@ the log line to close this out.**
|
||||
2. Record the hot-air rework outcome (RSSI response test) once attempted.
|
||||
3. If rework doesn't change the symptom: escalate to full chip removal +
|
||||
re-paste, or treat the PCBWay claim as the primary path forward.
|
||||
4. Blob/firmware-image integrity check (in progress, separate task): verify
|
||||
`GET_FUNC_INFO`/`GET_PART_INFO` revision strings and blob byte counts/hashes
|
||||
for the FM and DAB images actually loaded, to rule out a corrupt or wrong
|
||||
image as an alternative explanation to the EP hardware hypothesis.
|
||||
4. **New, separate issue**: BT1035 `AT init failed` at boot, now reproducing on
|
||||
every reset (was a one-off earlier in this session, now persistent/deterministic
|
||||
— same ~7.7 s timeout every time). Not yet investigated; may be related to
|
||||
physical handling of the board during the antenna soldering/rework work
|
||||
today. Blocks the full boot sequence (`hardware::HardwareBootstrap::boot()`
|
||||
halts `app_main()` on any companion-chip failure), so also blocks reaching
|
||||
Wi-Fi/HTTP and the FM boot path.
|
||||
|
||||
Reference in New Issue
Block a user