[ot][spam][crazy] The Trials of Controlling a Programmer

[Undiscussed Horrific Abuse, One Victim of Many]

Basically, if it detects an LPC chip, it cycles the LPC clock while it is
waiting for UART data.

>
That explains the clock going high when a chip is in.

I'm presently attempting to redo my troubleshooting ensuring I have no chip
in when sending the probe voltages (there wasn't one in the first time),
but the firmware debug terminal isn't loading.

I reset the board with its button and I can't seem to even open the serial
port. (I'm using screen; it immediately terminates on launch.)

I repowered the board, and it will connect, but not launch the terminal.

I thought I had reverted all my debugging traces and block comments, but I
found some in a submodule and reverted those too. After a rebuild and
reflash, it still won't launch the debugging terminal.

The arduino serial has leds for receiving and sending data. It's supposed
to switch to debug mode when I send it a spacebar. I can see it receiving
the spacebar character.

It sometimes takes a bit before responding to spacebars. I infer it's still
in the state where it doesn't.

I can theoretically debug it like I did the motherboard I'm working on, by
sending tracepoints to the serial line.

This arduino uno also appears to have a large removable socketed chip in it.

After a very long delay, it did eventually show the debug terminal, and
some spurious characters that appear to be local echo.

The clk pin finally goes low. No chip is in.

And it will actually read the chip data again!

I think this would have been less mysterious if the clk pin didn't
oscillate on its own under certain conditions when probing. I think I'll
either detect or disable that in the new debug command code.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 2532 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20220419/ddade6ee/attachment.txt>