Hi all,

before tomorrow's meeting I wanted to send around a couple
of files for documentation of the existing (v11) ICRR and
its interfaces with the TRACR (v2). It might be good
to find a place-archive for all future documentation, to avoid
having in the future (with other people dealing with other parts
of the project) to re-discover the wheels invented by the accidental
designer in charge (me, in this case).

The two files I attach describe my understanding of the interfaces
ICRR-TRACR and TRACR-DOM as they are now (and they seem to make
sense, even though certain choices - as that of calling READ an
operation that writes values downstream - puzzle me a little bit).

Furthermore, I have answers for most of the questions that were
raised last week. Quick summary here:

1. How to discover that an internal trigger took place?

ICRR generates a pulse at its SMB_TIMING output that I believe
it is directly sent to the DOM through the "special cable". Don't
know how the DOM deals with it then.

2. How to enable the reference clock (channel 9 of LABs):
write in virtual address 19 of the communication through the TRACR
(this implies writing - "reading" according
to the naming in the code -  at physical addresses 21 and 22 the
high and low 8 bits of the virtual address, and then issuing a write
- "read" - at physical address 23). Disabling it is accomplished by
similar operations at virtual address 20.

3. The current monitors (MON signals available for logic analyzers/scopes on the ICRR board) 
are the DATA coming from the TRACR board, and a few signals related to setting the reference DACs 
(not particularly relevant at this debugging moment).

4. How to enable reading the HK data only: use virtual address 24
(see point 2). V_A 25 turns the whole acquisition on.

5. The various modifications of the firmware we discussed: I am
close to a new version of the firmware, and it should be ready before
I leave. There are  a few things that are worth discussing tomorrow,
though.

Finally, on the most pressing issue of the ROVDD, unfortunately I did
not find any logical bug in the code as is (and a simulation seems
to work correctly), so it looks like it should be an analog/or wiring
issue, as Gary seemed to imply in one of the last mails. Hopefully
the next firmware will make debugging a little easier.

Any comment is welcome,

Luca.

P.S.: regarding the last observation, Peter, in reality I discovered
that  an initial reset is in fact in place, so we should not be
worried about it for the next firmware.