Oldgit, here's my debugging patch. I had to dig this out of some old sd990 development patches I had saved, so I'm not sure it's 100% right. It compiles, but I haven't tested it. The stuff in SD990 capt_seq should give you some idea how to implement it.
basic idea:
capt_seq runs in a loop, handling "messages" which are just numbers that get fed into a switch statement. We want to get an idea of which one is run in particular conditions, and record any random state we think might be interesting.
At the very start of the capt_seq loop, we store the message number and call capt_seq_log_msg, which stores the current clock tick (so we can see where in the sequence things happened), the words of physw_status (so we can see which buttons are pressed) and any other values we want to store at that point.
In capt_seq we can store flags to note that a particular point was reached (the cs_j1_cp etc). The particular values I'm storing here probably don't interest you, but you can use the same idea.
At the very end of the capt_seq loop, we call the second log function which stores those. (capt_seq_log_j1_cp). They don't go directly in the struct because it's I was too lazy to do it in ASM.
In core/kbd.c
s_msg_log_dump checks for half presses. Two seconds after half press is released, it dumps the accumulated messages to A/cslog.log and resets the log buffer to empty.
A sample log (from a slightly older version without the misc stuff) looks like this:
hp, shoot
--cs msg dump tick 23640-28290 n 7
23680 0x0 0x1CF420C0 0xFA49355D 0x00408FFE
25900 0x1 0x9CF424C2 0xFA493B1D 0x0040AFFC +2220
26870 0x20 0x1CF42CC2 0xFA49355D 0x00408FFF +970
26870 0x4 0x1CF42CC2 0xFA49355D 0x00408FFF +130
27000 0x1E 0x1CF428C2 0xFA49350D 0x00408FFF
27010 0x20 0x1CF428C3 0xFA493B5D 0x0040AFFF +10
27010 0x3 0x1CF428C3 0xFA493B5D 0x0040AFFF
hp, shoot is my note that I held half press and then did a full soot. The +N are also notes I made after the fact figuring out how long each step took (which could obviously be done in the log func)
The header shows when the half press was first detected, when the log was dumped, and how many messages there were. Each half press generates one of these. Note that you can get messages from before the half press started (e.g. from powering up the camera, or changing settings that trigger capt_seq messages). The buffer filling up was never a problem when I was playing with this.
The columns are
<tick> <capt_seq message number> <physw0> <physw1> <physw2>
here's my notes on what triggers different messages on sd990
shoot seq task jump table values
startup in playback:0
halfpress to shootmode:0x16 (22)
halfpress: 0, except move mode=8
released: 3
changed flash: 0x1a 26
focus mode change: 0x16 (22) except MF=0x15 (21)
p mode-> func: 0xF (15) on enter ev comp, 0x10 (16) on leave
iso change: 0x1b (27)
full shoot 1, 4 ?
