TDC7201: INTBx sometimes cannot fall

Hello Raimu,

Thanks for posting to the sensors forum!

Is it possible to get a capture of the START, STOP, and INTBx signal of a measurement that fails? I would like to confirm what the timing signals look like in the scenario when the INTB pin does not go low. 

Also note that the TRIG and the START pulse should not use the same signal as the datasheet recommends a 5ns delay between a TRIG and START signal on the devices. Is there a way you could try to delay the START pulse from the TRIG to see if this changes the behavior you are seeing?

For the 67ns wait time, there is some additional margin built into this spec but its not recommended that you provide an additional STOP lower than the 67ns as this extra time is needed to store the previous results and prepare the digital logic for the next STOP pulse. This margin accounts for variation across devices so its possible that you could get a device where its closer to the spec than the device that you tested.

I hope this helps, looking forward to your response!

Best,

Isaac

Hi, Isaac

sorry for lost description. We are using two TDC7201 devices, which together have four cores. The Start input pins of all four cores reference the same trigger signal. One TDC7201 measures the time difference between signals A and B, while the other measures the duration of signal B, which refers to the previously mentioned S2 and S3. Please refer to Figure 2, where the time difference between the TDC7201 output Trigger and the Start input is greater than 500 ns.

 Figure2

We understand that the timing specification requires the two Stop signals to be separated by at least 67 ns. However, in NUM_STOP, a single core can receive a maximum of five Stop signals in one measurement. In practical operations, it is not guaranteed that the intervals between Stop signals will be greater than 67 ns. We would like to inquire how the TDC7201 would behave if the interval between Stop signals is less than 67 ns (the lowest time we have currently observed is 40 ns).

Additionally, regarding the relationship between the Start (yellow), Stop (red), and INTBx (blue) signals that you wanted to understand, please refer to Figure 3.

P.S. The green signal represents the Trigger output from the TDC7201.

 Figure3

Looking forward to your response.

Best,

Raimu

Hello Raimu, 

Thanks for the information that clarifies things a bit. If the STOP is lower than the 67ns you can run the risk of the AFE not being ready for the STOP signal so the system will not recognize that it has received a STOP. 

Do you know how many STOPs the device was configured for in the scope shot above and do you know what the pulse width is for the STOP pulses? My only thought at the moment is that perhaps the pulses were not recognized as valid pulses hence why the device still thinks the measurement is happening and the INTBx remains high.

Best,

Isaac

Hi, Isaac

Thanks for the information that clarifies things a bit. If the STOP is lower than the 67ns you can run the risk of the AFE not being ready for the STOP signal so the system will not recognize that it has received a STOP. 

=> If I understand correctly, you mean that the TDC7201 may not be able to correctly receive signals with a duration of less than 67 ns, rather than the AFE, right?

Do you know how many STOPs the device was configured for in the scope shot above and do you know what the pulse width is for the STOP pulses? My only thought at the moment is that perhaps the pulses were not recognized as valid pulses hence why the device still thinks the measurement is happening and the INTBx remains high.

=> This is a single STOP signal, but there are three peak waveforms. The normal pulse width is 23 ns, and the 7201 is set to detect three STOP signals (NUM_STOP=010).

By the way, I would like to ask about the following questions regarding the graph (sometimes the Stop signal looks like the letter "M"):

 Figure 4

1. How does the 7201 determine the Stop signal? We know that the interval between STOP signals needs to be greater than 67 ns. In our actual readings, we have found that the TIME2 register sometimes has a non-zero value, and at times it is the same as the TIME1 register value. Under what circumstances does the 7201 consider there to be two STOP signals?

2. Will different TDC7201 chips read the same edge signal values the same way? For example, the rising edge of the Stop signal.

3. This question is unrelated to the graph, but I would like to ask how to calculate COARSE_CNTR_OVF. According to the specification,
(TDCx_TIMEn/63)≥COARSE_CNTR_OVF, and TDCx_TIME is related to Equation 1, where TOFn=(TIMEn)(normLSB).

Assuming the TOF time to be measured is less than 1 µs:

TDCx_CALIBRATION2: 21121
TDCx_CALIBRATION1: 2110
CALIBRATION2_PERIODS = 10
CLOCK: 8 MHz
Is it correct to set COARSE_CNTR_OVF to 268?

Best

Raimu

Hello Raimu,

1.  If I understand correctly, you mean that the TDC7201 may not be able to correctly receive signals with a duration of less than 67 ns, rather than the AFE, right?
   1. Correct the TDC7201 may not be able to correctly interpret signals if the duration between stops is less than 67ns, rather than the AFE.
2. How does the 7201 determine the Stop signal? We know that the interval between STOP signals needs to be greater than 67 ns. In our actual readings, we have found that the TIME2 register sometimes has a non-zero value, and at times it is the same as the TIME1 register value. Under what circumstances does the 7201 consider there to be two STOP signals?
   1. I would need to check with my design team so see how the logic is configured internally. Just to confirm is the time length between the first peak to the next peak less than 67ns?
3. Will different TDC7201 chips read the same edge signal values the same way? For example, the rising edge of the Stop signal.
   1. This is a setting within the device in the TDCx_CONFIG register. The STOP_EDGE register defaults to reading rising edges but it can be configured to read falling edges if preferred. So unless if the user changes this the default is always rising.
4.  I would like to ask how to calculate COARSE_CNTR_OVF.
   
   1. Do you have a target value of when you would like the overflow to occur? For example if the measurement is 1us then the interrupt bit should be set? If you provide the target value I can help on how  that should be calculated.

Best,

Isaac

Hello, Issac

1. I would need to check with my design team so see how the logic is configured internally. Just to confirm is the time length between the first peak to the next peak less than 67ns?

Please check with your design team. We would like to understand how the 7201 determines signals in relation to STOP signals that are below 67 ns and their voltage levels. Please refer to Figure 5. We believe that Label STOP2 should not have a measured value, but the 7201 seems considers that it does, even though the voltage is below 0.7 VDD (Vih). Is this a normal determination?

 Figure5.

2. Do you have a target value of when you would like the overflow to occur? For example if the measurement is 1us then the interrupt bit should be set? If you provide the target value I can help on how  that should be calculated.

Sorry, what does the interrupt bit refer to? We want to measure the TOF within 1 µs and expect that 1μs>COARSE_CNTR_OVF, which will also generate INTBx. In our previous conversation, we calculated that value to be 268 (0x10C). Is this correct, or could you advise us on the correct calculation?

Following up on, will INTBx be generated early if the number of completed STOP signals received and does not exceed COARSE_CNTR_OVF? Additionally, if not completed, will writing 1 to START_MEAS in CONFIG1 force a re-measurement, or will it continue to wait for the STOP signal?

Best

Raimu

Hello Raimu,

I have forwarded the first question over to my design team, I will get back to you on that item once I get a response from them.

For question 2, the value that I calculated for my system is 294. So I would program 0x0126. I am using an 8MHz clock for the EVM 

Essentially the way I calculated the appropriate value is using the following ((1us/normLSB)/63)= COARSE_COUNTER_OVF. 

The INTBx can be generated early if the number of STOP signals is met but you have to keep in mind that there is an associated time with storing the data in the registers and the INTBx pin will not drop low until the data is ready to be read. So even though the sensor overflows at 1us the INTBx may take longer to fall if the STOP conditions are met.

START_MEAS will start a measurement will restart a measurement regardless of the previous status.

I hope this helps!

Best,

Isaac

Hello Isaac,

We look forward to your team's suggestions and await your response.

We are using the same formula. However, our calculated result is 268 (0x10C). The values are different but close; I suspect this is due to TDCx_CALIBRATION1 and TDCx_CALIBRATION2.

How much time is needed after storing the data for INTBx to drop? Is the maximum data storage time 800 ns?

Best

Raimu

Hello Raimu,

That is correct there will be slight differences in the calculated value due to the calibration values on your system.

Unfortunately this is something that we dont have a specification for but I have seen cases where the INTBx can take up to 2us to assert low. 

I am not sure where the 800ns are derived from.

Best,

Isaac

Hello Isaac,

800 ns is the value we are currently encountering and suspecting. As an additional note, does the 2 us include the COARSE_CNTR_OVF time?

Thank you for your message. If there are no clear specifications for INTBx, we will take other approaches.

Finally, we will wait for your team's reply regarding how to determine the STOP signal below 67 ns in relation to Vih/Vil for the 7201.

Thank you for your patient response.

Best
Raimu

Hello Raimu, 

Got it thanks for the details, the 2us is something I measured on my end as a worst case scenario with a couple of units. For the 2us scenario, this had all 5 stops enabled as well as averaging configured on the device. When the COARSE_CNTR_OVF is used its typically relatively faster that the 2us since not as much info has to be stored or no other calculations have to be performed.

I am still waiting for the design team to look into the expected information on the STOP pulse below 67ns, so I will update the thread once I have details from them. And no worries glad to help out!

Best,

Isaac

Hello Isaac,

"Sorry, I just thought of something. The maximum measurement time for Mode 1 is 2us. This is different from what we discussed regarding the STOP receiving enough counts and exceeding the COARSE_CNTR_OVF setting. In the longest situation you've seen, INTBx does not go low for more than 2us, which has a different meaning, right?"

Best

Raimu