TDC7200 register config for single stop, no timeout

Hi Vishy --

I have commented out all the writes to STOP_MASK and the overflow registers to leave those at default.

At initialization, I am writing 0x80 into CONFIG2 to set 20 cal periods, then before each measurement writing 0x83 into CONFIG1 to force cal, set mode 2, and enable measurement.

With those settings, I never get an INTB flag. To ever get a result, I need to set CLOCK_COUNTER_OVF to some amount greater than the TOF, and I get INTB after that time.

What register values should I be using for this situation (again mode 2, 20 cal periods, one stop)?

Thanks!

Thanks for all the help, Vishy. But I am getting *very* strange results. Basically, if I write 0x80 into CONFIG1 (or 0x00) with everything else as default, I do not get INTB from the chip. If I write 0x81 or larger (ie, 2 stops), then I get INTB but only after about 6ms, which is close to the maximum interval for the 10 MHz clock I'm using.

It seems like the real problem is that I can't set for just 1 stop event; it requires at least two (0x81) to trigger INTB.

I am timing slow rate, fast edge (testing with 1 pulse per second) events that last from 300ns to a bit over 100us from START to STOP. This is my own board, and INTB is pulled high -- and I get great performance if I allow measurements to time out. However, I'm trying to speed up the cycle time and this measurement interrupt thing is driving me nuts!

Hi Vishy --

I am not using the TRIGGER signal (I know...). However, the event rate is low (1 per second for this testing). The loop is pretty much:

setup // CONFIG2 0x80, but that doesn't work -- only 0X81 through 0x84 work
while (1) {
if (!INTB) {
readchip()
enablenextreading() // CONFIG1 0x83
do some calculations and output
}
}

It takes the processor only about 1 millisecond to do all this (other than the time waiting for INTB) and the START event rate is 1 per second (this is running on an Arduino). So the system just loops for almost a second after enabling the next measurement, and I don't believe we are underrunning the setup time.

I'm not sure I can easily extract the TDC from the multi-page schematic, and the full schematic isn't quite ready for public view at this point. I can email to you if you'd likeut wouldn't want to post it to the forum publicly. One thing to note is that hardware logic guarantees that the START->STOP time will be between 300ns and 1.3us.

However, if it helps both START and STOP are being driven by on=board 3.3V logic. The clock is at 10 MHz and comes from a reasonably high-quality external timebase (OCXO) through a sine-square converter circuit that is well tested. INTB is pulled up through 1.5K The TDC has the recommended bypass caps, mounted very close to the chip. The board is 4 layers with VCC and ground planes on the inside. None of the TDC-related traces are more than about an inch long.

What scope shots would be helpful? I can try to take some tomorrow, though at the moment I only have a 100 MHz scope available so may not spot very fast glitches.

Thanks for your patience helping me work through this.

Hi Vishy --

We have discovered a possible logic glitch that might explain this (or another related) problem. We have some hardware gates that supply the STOP signal to the chip. When INTB triggers after a STOP event, it clears the logic and returns it to a low state.

It turns out that logic could glitch and lock high at startup, which means the TDC sees STOP before START and it causes problems in other parts of the circuit as well).

So, we need to assert INTB momentarily after startup to clear that condition.

Is there a set of register values we can write in our setup routine that would cause INTB to assert regardless of the START or STOP states? That would allow us to clear the logic and then proceed with initialization as normal. If not, we'll have to look at a (hopefully blue-wire) hardware change.

Thanks!