mckero e5166dba02 Round 56: the DMA transfer carries the correct bytes end to end; the six bytes come later ...

A window probe on the DMA loop logs the byte the transfer actually carried at fixed indices. For the run whose rx_addr is the overlay the last lines are idx 0 f0 (correct), idx 1 b5 (correct), idx 2444 00 (correct), idx 2445 00 (correct). Earlier lines belong to other, shorter transfers carrying 0xff or the FAP1 bytes, so the load is a sequence and the one that lands carries the right bytes everywhere, including the window that ends up wrong.

DMA and flash paths are exonerated for the last time. That also opens the possibility that the overlay is correct at transfer time, the CRC passes, the app actually runs, and the six bytes are a post-mortem symptom rather than the cause -- the next measurement reads the overlay back within a fraction of a second of MENU and hashes it.

Own mistake recorded: the window probe was meant to write four lines and wrote 2088, because a condition on the loop index alone also matches every short transfer that starts there. This file warns about capping a diagnostic before knowing the shape of the data; this was the same rule in the other direction.

2026-10-02 13:28:13 +08:00

..

armv7m_systick.c.patched

UV-K5 V3 emulator: QEMU machine for the PY32F071

2026-08-27 14:59:21 +01:00

armv7m_systick.h.patched

UV-K5 V3 emulator: QEMU machine for the PY32F071

2026-08-27 14:59:21 +01:00

py32f071.c

Round 56: the DMA transfer carries the correct bytes end to end; the six bytes come later

2026-10-02 13:28:13 +08:00