the LPC socket was sometimes showing the issue previously, refusing to find the LPC chip unless I reinserted it a number of times.
But I did try to gently bend some leads to resolve connection issues, and
thinking on that I guess that means I might have a way to consider whether I'm testing the chip leads or socket leads.
Then later, I tested connections from the chip seating all the way to the
teensy board, and found a number that were failing due to wear on the breadboard, and adjusted and squeezed these until they conducted. But it still wouldn't detect a known-working chip.
I then removed it from the breadboard and wired it up hanging in the air with female jumper wires. This is not working either.
It sounds like there are two issues: a failing socket, and failing wire connections. Not considering that there are likely two separate kinds of issues could have worsened the confusing frustration.
I'd like to compare the electrical activity at the chip pins to what the
device is supposed to send somehow.
Maybe I could try to add debug information to flashrom's serprog protocol, although I'm feeling that might be inefficient.
It's important to eventually have logic debugging. But maybe something more reusable than serprog additions. Thinking about testing manually vs building or finding logic probing tools, one thinks about time. Both tasks are slowed from human issues. I bet there's existing code to use raspberry pi as a logic analyser somewhere ... but I'm unsure if the frequency will be sufficient without learning the flashing protocol. Learning the protocol would normally be expected for hobbying this. Thinking on manually testing things with more rigor. Ensuring the chip used works. Considering every pin in all the ways, and verifying they all work before a test. It's frightening to think of putting all that work in and having it still possibly fail for unknown reason, but it may be an important and rational diagnostic step. One that has not yet been done.