mirror of
https://github.com/MCKero6423/uv-k5-v3-emulator.git
synced 2026-10-08 13:47:24 +00:00
mckero
a210e531dd
The GPIO model's output path is correct -- py32_gpio_update fires every changed pin's line and the write path covers ODR, BSRR and BRR -- so that link is not the fault. Instrumenting the two things the row rule needs together, the key state and the column drive, gives zero keypad_col_changed calls while F is held for eight seconds, with odr stuck at 0x00000004 and the firmware reading the input register three million times. col_high therefore keeps its reset value, every column high, and the row rule's condition can never be true: that is the whole of why no row ever goes low. And odr's bits 3..6 never change, so the firmware's SetOutputPin(PIN_COLS) and ResetOutputPin(PIN_COL(j-1)) never reach the model at all. A device that is polled but never driven is the signature of a binary that does not contain the code being read. That points at the thing this file warned about early and which I did not check before twenty rounds of notes: work/dl_*.c is the Labs build, and the notes themselves record that the page's firmware is 109.3 KiB while the Labs build is 111.9 KiB -- two different builds. So the next step is an identity check rather than another probe: establish what the binary under test is, by banner, size and CRC, and put it beside the source it was built from.