This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDC7200: Measurement sometimes doesn't complete

Part Number: TDC7200
Other Parts Discussed in Thread: SN74LVC3G17, SN74LVC1G74, ADS1248, TDC1000

I've got a weird issue:

- I start a measurement (CONFIG1=c3h, all other registers at their default values, CLOCK is 16 MHz)
- in response to that, TRIGG transitions from low to high
- 500 ns later, INTB transitions from low to open (if it wasn't already open)
- 3000 ns later, START transitions from low to high (and stays high for the rest of the measurement)
- in response to that, TRIGG immediately transitions from high to low (ie, the TDC7200 does see the START edge)
- 10000 ns later, STOP transitions from low to high (and stays high)
- in about 4 out of 5 cases, measurement terminates successfully (INTB goes low)
- in about 1 out of 5 cases, nothing happens: INTB stays open and the registers indicate the TDC7200 is still measuring, without overflow.

As no overflow happens, I conclude that the TDC7200 has missed the START edge, though it makes TRIGG go low. That is, the TDC7200 both sees and ignores the START edge.

Any idea what's wrong? Is there a maximum value for the time between TRIGG and START (the datasheets lists only a nominal value, no maximum value)? Is there a maximum value for the duration of the START pulse (the datasheet lists only a minimum value)? Does START have to be low for STOP to be detected?

  • Hello Claus,

    Thank you for the question. I tested with the same conditions that you described above but was not able to replicate the issue.

    While the datasheet only gives the minimum time required from TRIGG to START it does not have a maximum value, I did test a couple of conditions much longer than your test case noted you above and the device was still waiting for a START pulse after 20us and produced correct results when a STOP pulse was sent to the device after that hold time. 

    One thing that I did note is that TRIGG will toggle low regardless of receiving a START pulse right away or if I waited 20us. This might not be the best indicator if the START pulse was received by the device or not. I attached an image below that demonstrates this, the purple signal is TRIGG, yellow is START, cyan is STOP, and green we have INTB.

    To answer your second question, no START does not have to be low before a STOP pulse is detected. The image below produced a correct result even though the start pulse was still high when the STOP was received.

    One thing to check is if your START and STOP pulse widths are meeting the necessary length they require at least a 10ns pulse. If they are not meeting the necessary pulse width then this might be a reason why the device is indefinitely trying to complete a measurement.

    Is the testing being done on a custom board or on one of our EVM's?



  • Thanks for looking into this. Both the START and STOP pulses are about 5 seconds long, that's well above 10 ns. Testing is done on a custom board (with plenty of decoupling caps, but I'll add even more just in case). In the meantime I being desperate tried "sharpening" the edges of CLOCK, START, and STOP with an SN74LVC3G17. No difference. I also tried resetting START when STOP arrives (SN74LVC1G74). That changes the situation indeed: now I have the well-known unsolved problem of TIME1 sometimes being totally wrong (way above CALIBRATION2) for measurement mode 2. That issue was raised a couple of times on this forum. But measurement always completes, albeit with unusable results.

    Probably will try monoflops for START and STOP next (hoping they won't skew the signals too much in the final product).

    BTW, the probability of TIME1 being totally out of range seems to increase with decreasing distance between START and STOP, which is weird as STOP shouldn't affect TIME1!

    I'll also try to find out if letting START and STOP stay low for a longer time before the measurement makes a difference. I think the datasheet doesn't specify a minimum value for that time, but there certainly must be a minimum value.

    I'll also try another TDC7200 chip as the one I'm testing with could be faulty.

    Any other ideas?

    P.S.: how many times did you perform the experiment of raising STOP while START is still high?

  • Hey Claus,

    Just to make sure I understand this correctly, ensuring that the START pulse ends when the STOP arrives fixed the issue where you were missing a measurement, but this brings you to another problem of TIME1 having an incorrect value. Is that correct?

    I do think the 5 second pulse width sounds a little long, so maybe reducing the size of the pulse to ensure that there is ample time before the next measurement commences might make a difference. Like you mentioned there is no spec but I have not tested running such a long pulse width, we usually have the opposite problem of different users attempting to run really small pulse widths.

    I have not encountered the issue of TIME1 giving incorrect values, I am not sure how easy this is to setup on your system but perhaps try generating two stop signals and see if TIME2 is generating the correct results. If you enter a known delay between STOP 1 and STOP 2 this might be a usable workaround.

    Back to the original problem of no measurement being completed, it seems like this user had the same problem it might be worth it check your SPI lines as mentioned here:

    I performed the experiment of toggling STOP high while START was still high a couple of dozen times, I had a user ask about this same instance a couple of months ago. I can double check with your settings to see if it does perform as intended. What is your expected ToF?



  • Hi Isaac,

    yes, using the rising edge of STOP to end the START pulse makes measurements terminate, but with unusable values for TIME1 in measurement mode 2. How often TIME1 is out of range seems to depend on the distance between the rising edges of START and STOP (which equals the START pulse width in this scenario). For a ToF of 3 microseconds, TIME1 is nearly always totally unusable (beyond 100,000 with CALIBRATION2 being about 12,000). I'm not the first one to experience this, see, e.g., And yes, this is measurement mode 2. Confirmed by reading CONFIG1.

    Only TIME1 is affected, TIME2 through TIME6 are always reasonable (but I have not yet checked whether they are correct).

    The expected ToF is between 5 and 100 microseconds.

    I'll add a small FPGA (or a GreenPAK) to simplify testing with different START/STOP pulse patterns generated from the incoming signals. That will probably take some time. I could generate a dummy START pulse and turn both incoming pulses into STOP pulses (rather than START and STOP) so that I can measure the time between the two STOP pulses. I'd prefer to fix the original problem, though.

    Thanks for the link to the SPI/CSB issue! That looks promising, I'll probably try this first. My SPI speed is 562.5 kHz.

  • Hey Claus,

    Thanks for the info. I will try to see if I can replicate this on my setup but will likely not get to it today, so I will try to update you on this tomorrow.

    Yeah I would check the SPI/CSB issue first to make sure this isn't what is causing the problem for your missed reads. Then try replacing the TDC7200 to ensure that the one you have is not faulty.

    Would it be easier to implement if you used a real START like you normally intended, then create a dummy STOP a couple of nanoseconds in to overcome the incorrect TIME1 reading and let the second STOP generate naturally like intended to get a correct results for TIME2. Just a thought but like I mentioned I will be trying to test this issue to see if I can recreate it on my end.

    If you have chance to collect a screen capture of the START, STOP, INTB, and TRIGG pulses for a bad measurement it might help me recreate the problem easier and hopefully find a solution or a better workaround. I assume your settings are the same as mentioned at the beginning of this thread so if anything has changed please let me know.



  • Hi Isaac,

    I don't think adding a dummy STOP pulse would help as I'd end up with an unusable START-to-STOP1 measurement and a correct STOP1-to-STOP2 measurement from which I cannot compute START-to-STOP2. Ditto for a dummy STOP2. That's why I thought about using a dummy START pulse and generating two STOP pulses from the start and stop inputs, that is, the start input generates a STOP pulse of a suitable length and the stop input generates another STOP pulse.

    I had a logic analyzer capture containing the TRIGG, START, STOP, and INTB timings which I transcribed to English in the original post. Unfortunately, I didn't save a screenshot.

    If CSB (and/or the falling edge of START for the second scenario) turns out to be the culprit: do you think that's a logic error or some AC interference in the TDC7200? If it's the latter, smoothing the edges (rather than sharpening them like I did) might help. The ADS1248 datasheet recommends using 47 ohms resistors on all data lines.

    Enough for today. Thanks!

  • Hi Isaac,

    I made a couple of experiments with the original circuit (START stays high for 5 seconds):
    - new TDC7200 chip: no difference
    - 1.125 Mbit/s SPI clock: no difference
    - 2.25 Mbit/s SPI clock: no difference
    - 4.5 Mbit/s SPI clock: no difference
    - 9 Mbit/s SPI clock: no difference
    - 18 Mbit/s SPI clock: no difference
    - 36 Mbit/s SPI clock (out of spec): does not work at all
    - 47 ohms for CSB: no difference
    - 100 ohms for CSB: no difference
    - 47 ohms for START: no difference
    - 100 ohms for START: does not work
    - 47 ohms for STOP: no difference
    - 100 ohms for STOP: does not work
    - tweaking the code to set CSB high as soon as possible: no difference
    - keeping CSB low after setting CONFIG1: does not work as the TDC7200 does not load the value written until CSB goes high
    - ensuring that START and STOP are low for 500 ms before measurement begins: no difference
    - writing CONFIG1 twice (first with START_MEAS=0, then with START_MEAS=1): no difference
    - additional bypassing caps for VDD of the TDC7200: no difference
    The results are the obvious ones when combining those experiments.

  • More experiments:
    - another decoupling cap for VREG: no difference
    - read back the registers to make sure they are written correctly: they are.
    - measure VDD: 3.26 V
    - measure VREG: 1.66 V

  • Hey Claus,

    Thanks for the info I will be looking through it shortly, what are your settings on CONFIG2?



  • Hi Isaac,

    CONFIG2 is at its reset value 40h.

  • I had another look at the datasheets: The TDC7200 datasheet does not specify a maximum rise time for START and STOP, only a nominal one, 1 ns. The SN74LVC gates I use in front of START and STOP seem to have a rise time of about 3 ns. The TDC1000 datasheet specifies a typical rise time of 0.25 ns for the START and STOP outputs. Quite a difference.  I'll try SN74ALVC gates.

  • SN74ALVC gates for driving the START and STOP inputs of the TDC7200 do not help. However, I'm testing on a breadboard now which adds capacitance, smoothing the edges.

  • Hey Claus,

    Thanks for the info. I have been able to replicate the error but I am still trying to figure out what is causing it. What are the values you are obtaining for CLOCK_COUNT1 on your system?



  • Hey Claus,

    It seems like I was only able to replicate the issue whenever I had PARITY_EN set to 1 for even parity. Once I set this back to 0 I was getting steady usable values for TIMEx and CLOCK_COUNTx. When the bit was enabled I was able to get usable values intermittently at certain STOP times while others would not produce any usable values at all. Let me know if this makes a difference in your system.



  • That has to wait for tomorrow as my system is currently wired for "START remaining high for 5 seconds" (that is, measurement doesn't always complete) rather than for "STOP makes START fall to low" (TIME1 often out of range). You did set the parity bit to zero before displaying the values, didn't you? ;-)

    WIth my current system, CLOCK_COUNT1 is 160.

  • Sounds good, feel free to keep me posted if it works. Thankfully I am using the GUI and it seems to take care of that for me.(:

    But that sounds like a reasonable CLOCK_COUNT value, when I had the parity bit enable sometimes I would get a value significantly higher than that.



  • Hi Isaac,

    CLOCK_COUNT1 always is reasonable. TIME1 is the problem (in the second scenario).

    If your GUI displays values greater than 8388607 (7fffffh), it failed to clear the parity bit for display.

    Back to the original problem: I added some logic which turns START and STOP into 100 ns pulses, that's well above the minimum pulse width required by the TDC7200 and well below my ToF. The other timings are as in my first post. Now I get both problems with the same circuit: measurement sometimes doesn't complete and TIME1 is sometimes totally out of range. The value of the PARITY_EN bit doesn't make a difference. All registers are at their default values (except for the START_MEAS bit, of course).

    The worst value I got for TIME1 is 2293676 with CALIBRATION2 being 11186, that is, the ring oscillator was running for more than 20 clock cycles (if we can trust the TIME1 value reported by the TDC7200).

    The thread you pointed at above ( is probably a red herring. As the TDC7200 doesn't register the START_MEAS bit until CSB goes high, the SPI speed is totally irrelevant. Unless register polling is used, all SPI communication happens while CSB is low and measurements happens after CSB rises to high.

    BTW, using 8 MHz instead of 16 MHz for the CLOCK input doesn't make a difference.

    I'm running out of ideas

  • Two more (last?) experiments:
    - MAX22344 for shorter rise time of START and STOP (max 1.1 ns into 5 pF): no difference
    - different power supply: no difference

    Looks like I have to give up and choose a chip that actually works.

  • Hello Claus,

    Sorry to hear that did not work out for you. It seems like the GUI might have not been taking care of the parity bit in all instances then. So reducing your pulse widths causes your measurement not complete or did you revert to not resetting START when your STOP arrives?

    What were you getting for your TIME2 value when you got the largest TIME1 value?

    But I believe you are right about this thread: It seems like the user in this instance was accidentally toggling CSB during a measurement triggering a read but that didn't seem to be the issue in your case. I have not encountered this problem before so I am curious to what could be causing your measurements not to START or not STOP appropriately.

    I tired slower rise times to see if I could replicate the problem and I was still not seeing an issue.



  • Hi Isaac,

    TIME2 is always reasonable, ie, smaller than (CALIBRATION2-CALIBRATION1)/10. Here is an example of register values I get (hexadecimal register number, hexadecimal value, decimal value):

    10: 1f8a53 2067027
    11: 00009f 159
    12: 000106 262
    13: 000000 0
    14: 000000 0
    15: 000000 0
    16: 000000 0
    17: 000000 0
    18: 000000 0
    19: 000000 0
    1a: 000000 0
    1b: 00047f 1151
    1c: 002ce5 11493

  • New experiment:
    - waiting 1 ms between sending CONFIG1 with START_MEAS set and raising CSB: measurement never completes!
    Now that's a hint.

  • More experiments:
    - change SPI clock polarity to idle low: no difference
    - reduce time between last SPI clock pulse and rising edge of CSB to 2 microseconds (by turning on full optimization): success rate increases somewhat
    - reduce time between last SPI clock pulse and rising edge of CSB to 2 microseconds, change SPI clock polarity to idle low, and increase SPI clock rate to 1.125 Mbit/s: success rate increases even more

    That thread you pointed out might be the path to success after all!

  • I changed my code to leave CSB low after sending CONFIG1 with START_MEAS set and had a look at the TRIGG output: The TDC7200 starts measurement as soon as it receives the START_MEAS bit, without waiting for CSB to rise!

    The START_MEAS bit happens to be the last bit of CONFIG1 sent.

    In fact, the datasheet says "The serial data is loaded into the register with the last data bit SCLK rising edge when CSB is low."

  • Now an experiemt with all these measures combined:

    - reduce time between last SPI clock pulse and rising edge of CSB to 2 microseconds
    - change SPI clock polarity to idle low
    - increase SPI clock rate to 2.25 Mbit

    This looks like a winner. 700 successful measurements so far, the maximum value of TIME1 is 1259!
    Thanks for referring me to that thread!

    Conclusion: For a successful measurement (INTB signaling completion and TIME1 being reasonable), SCLK must be low and CSB must be high 2 microseconds or less after the falling SCLK edge for the START_MEAS bit.

    The TDC7200 datasheet says: "SPI clock can idle high or low." That's wrong.

    Perhaps the SCLK condition for successful measurement is this: SCLK must not toggle  x ns after the falling SCLK edge for START_MEAS, that is, it might be possible to use idle high for SCLK if the clock rate is sufficiently high.

  • Bad news: I went back to my original board with long START and STOP pulses and both problems are back: measurement sometimes (2%) doesn't complete and TIME1 sometimes is garbage  The latter one occurs even if START doesn't toggle with STOP. Probably measurement originally hung too often to see the second problem. At least I'm down to 2% from 20%. Increasing the SPI clock rate might help.

  • I changed the SPI clock to 18 Mbit/s and reduced those 5 seconds to 100 ms to speed up testing: 5000 successful measurements so far, with reasonable values of TIME1. Probably those 2 ms were still too long.

    Enough for this week.

  • Hi Isaac,

    over the weekend, nearly a million of measurements were successfully performed, with reasonable values of TIME1. I did also some tests with the CPOL=1  which I'll put into my summary of this thread.

  • Here's my summary of this thread:

    There are two symptoms which occur intermittently:

    (1) the TDC7200 sets TRIGG high, there are rising edges for START and STOP at suitable distances, but measurement never completes (INTB stays high)

    (2) TIME1 has an unreasable value, way above CALIBRATION1.

    Both problems are caused by SCLK or CSB changing during measurement. I haven't checked whether DIN is also affected. Measurement starts at the falling edge of SCLK for the START_MEAS bit while CSB is still low. Measurement never completes if CSB remains low. Therefore, we have to force CSB high very quickly after that falling edge of SCLK. With CPOL=1 (SCLK idles high) we have the additional problem of there being another (rising) edge of SCLK after measurement started.

    As the MCU I chose doesn't have hardware CS for SPI (no, NSS doesn't help), I made my own hardware CS with programmable delay for driving the TDC7200's CSB pin. I measured that if CSB is raised 1160 ns or more after the final falling edge of SCLK, both problems will occur. The longer that interval is, the higher is the probability for the problems to occur. Above 10000 ns, measurement never completes. Below 330 ns, measurement always completes and TIME1 is always reasonable. Due to hardware limitations, I don't have results for intervals between 330 ns and 1160 ns. (All these values are for CLOCK at 16 MHz.)

    - put the TDC7200 on its own SPI bus
    - raise CSB as quickly as possible after writing CONFIG1 with START_MEAS=1
    - use hardware CS for CSB if possible
    - use CPOL=0 (SCLK idles low) as you won't have to wait for the final rising edge of SCLK which wastes half an SCLK cycle for CPOL=1 after starting measurement
    - if you nevertheless use CPOL=1 (SCLK idles high), CSB must be controlled automatically by the SPI hardware as the MCU is too slow for raising CSB quickly enough in software
    - if you cannot use hardware CS, disable interrupts to avoid any unexpected delay between writing CONFIG1 and raising CSB
    - use as high a SCLK frequency as possible (the TDC7200 supports up to 20 Mbit/s). There might be an additional half SCLK cycle delay after the last bit to enforce the minimum SCLK pulse width for back-to-back transfers
    - as recommended by the datasheet, use INTB rather than polling the INT_STATUS register (remember, SCLK and CSB must not change during measurement)

  • Hey Claus,

    Thanks for the due diligence here and the nice hefty list of recommendations. It seems like you were able to identify the problem pretty clearly. I am glad that the thread helped out to figure out the issue I will look into the SCLK changing during the measurement causing measurements not to complete and try to update the datasheet as necessary. 

    If you could please mark this as solved so that other users can use this thread if they run into this problem!



  • I might be wrong about SCLK. On the other hand, CSB certainly must not be toggled in a certain interval that begins some 100 ns (for CLOCK at 16 MHz) after the falling edge of SCLK for the START_MEAS bit. Where the interval ends I haven't tried to find out. Maybe when TRIGG becomes active or, worse, when INTB becomes active. Maybe TIME2 etc. will be clobbered if CSB is toggled after the START pulse. So much to research, so little time available.