TIDA-00663: Time1 < Time2 issue

Hello, please let me check to have the right engineer to support you on this topic.

Hello Denge,

Thanks for posting to the E2E forum. It looks like the scope capture you mentioned above was not attached.

Also can you further explain what you mean by asymmetric INTB behavior?

I am not super familiar with the reference design mentioned here but if there are questions regarding the TDC7200 I can definitely help you get those figured out.

Best,

Isaac

Hello Isaac,

Correct, the attachments were not added for some reason.  I hope his time it will work.  Some clarification:

the yellow trace is the stop pulse of the 1e TDC and the cyan trace the stop pulse of the second TDC.  The magenta pulse is the start pulse for both.

The asymmetric behaviour of the INTB signals is best explained in the trace green / magenta.  Here magenta corresponds to the yellow pulse and green to the cyan one.

I'm still encountering T1 < T2 on one or both TDC's without any obvious causetek00005.tiftek00004.tif

Hello Denge, 

Thanks for the scope captures and the clarification. I can see what you mean regarding the asymmetrical INTB pulses. I know you included the the reference START pulse for both the TDC's in one of the captures but is it possible to measure the START pulse near each pin if not on each pin of the device? My concern is that perhaps there is some board parasitic that are causing a delay on one of the signals. Some questions on my end:

Is the schematic the same as TIDA-00663? Was the same board layout used?

Is it also possible to provide the device configurations for each of the TDCs? and result registers for each one of the devices?

On another note, we do offer the TDC7201 which integrates two TDC7200s together.

Best,

Isaac

Hello Isaac,

The start pulse on the pin is very steady as you see in the green trace.  This one is generated by the processor while the stop signals are generated by a two channel AFG and fed, into the board by (quite cheap) cables. 

The schematic is based on the TIDA-00663 but for now stripped down to the processor (DSPic33), 2 times TDC7200, a SiT2024 (16 MHz oscillator) plus the decoupling caps.

I've also been digging into the firmware but can't find any strange things causing the T1 < T2.

Each new measurement starts with writing 0b00000011 to the config 1 register to put both TDC in mode 2 and start the measurement, config register 2 stays default on all 0's.

The results are the following:

StatusTdc2  00011001
StatusTdc1  00011001
Result1  89.82031250000000000
Result2  139.8593750000000000
Result3  50.03906250000000000
Time1Tdc1  1163
Time2Tdc1  669
CalReg1Tdc1  1314
CalReg2Tdc1  13104
CalReg1Tdc2  1286
ClkCnt1Tdc1  14
ClkCnt1Tdc2  22
Time1Tdc2  1137
Time2Tdc2  566
CalReg1 1286
CalReg2Tdc2  14899
ErrorCount  0x3F68

tek00007.tif

Hello Denge,

Thanks for the info please let me review the information and get back to you.

Best,

Isaac

Hi Isaac,

I've some additional information: I added two 16-bit counters counting the T1 < T2 events for both TDC's and plotted the results (see screenshot).

The op trace is the delay between stop TDC1 and TDC2 going from 50 ns to 1.8 µs.  The bottom traces are both error counters, wrapping around when reaching 0xFFFF.  What is strange is that the slope of the graph is steady when the delta time is steady but increases when changing this time.

I still have no idea why this situation is occurring.

Hello Denge,

Thanks for the plot. I am not sure if I understand that the upper graph means here, is this what you mention to be the delay between TDC1 and TDC2? It seems like this error is continuously happening since your error counters essentially look like a pretty steady sawtooth. I still have not had a chance to look at your results to see if I can spot an issue there.

It seems like you did not provide the configuration for each TDC though, do you know what each device is configured to mainly looking at the CONFIG1 and CONFIG2 registers here to make sure the settings match.

Best,

Isaac

Hi Isaac,

You understood it correctly regarding he upper plot.  It is indeed the time delay between the two stop pulses of both TDC's.

The setup of both config registers is for both the same: each measurement starts with writing a 0b00000011 to CONFIG1 register (mode 2 + setting the start measurement) while CONFIG2 register is left to it's reset state being 0b0100000.

The error occurs indeed in a steady manner!  I added a new plot with the successful measurements and this reveal that only one out of four measurement is correct...

Groeten,

Hans

Hi Isaac,

It was a typo for the CONFIG2 register.  CONFIG2stays in it's reset state 0b0100 0000 so 10 clock periods calibration, 1 measurement cycle and Single stop.  So this should be OK, correct?

I'm indeed using the formulas from section 8.4.2.2.1 and the results -when correct- are pretty close to the delay I set on the AFG.  The only thing that keeps bothering me is the question why the results for the time registers are so frequently wrong.  I added another plot with the time registers 1 & 2 of both TDC's and I guess they speak for themselves. from the bottom traces where 1 is a negative result for T1-T2.

The SPI clock is 10MHz so within spec.  The reading are only done when both INTB signals are low...

A question: is it useful to reset the TDC's by pulling the ENABLE pin low after such error?

Good weekend,

Hans

Hello Hans,

So for a typical measurement are you only getting one set of results for the TimeX registers? If you are configured to 1 expected STOP pulse then you should not be reading more than 1 result from these registers.

Can you provide me a set of data for bad measurement on both TDC1 and TDC2 as well as what time you have configured on the AFG to see if we can somehow correlate what your reading out of the device? Also provide me your calculation for ToF to ensure if its being performed correctly. Perhaps there could be an error in the processing that is yielding an incorrect result. I don't think you should be getting this level of errors from the device.

Best,

Isaac

Hi Isaac,

I do not agree with you that only one time reading is sufficient when configured to 1 expected stop pulse in MODE2 seen the formula in 8.4.2.2.1 contains TIME1 and TIME2.  

For the data set, what do you exactly mean?  A spreadsheet with the results from the time readings for example?

The settings of the AFG are pulse burst, one  pulse on each channel with a width of 100 ns on each trigger, the time distance between the pulses is variable and the stop pulse of TDC1 always comes before the stop pulse of TDC2.

I forgot to ask in previous conversation: do you see a similar spreading/fluctuation in the T1 and T2 values at your place or are they far less jumpy?

I added the calculations in assembler written for a dsPic33EPxxxGPxxx microcontroller.   Note I rearranged the calculations from the formulas in 8.4.2.2.1 in order to obtain a better scaling.

Groeten,

HansMain.s

Hello Hans,

The additional TIMEx readings are used to obtain the ToF between the first STOP pulse and the other multiple STOPs. If only configuring a single STOP value then only a single TIMEx value is required. Please view my real life example below of what the data provides when using the calculation as shown in the datasheet.

In this example I set the device up to have a ToF STOP in ~0.5us. This is what I am reading from the device:

TIME1 = 9238

CALIBRATION1 = 2317

CALIBRATION2 = 23156

CLK_COUNT = 0

TOF = normLSB (TIME1- TIMEn+1) +(CLOCK _COUNT)(CLOCKperiod)

ToF = 0.0539853E-9*(9238) = 0.4987us 

As expected I obtain ~0.5us.

Now if I configure the device to accept two STOPs and add the other STOP pulse at 2.5us then

TIME1 = 9239

TIME2 = 46264

CALIBRATION1 = 2317

CALIBRATION2 = 23141

CLK_COUNT = 0

TOF =  0.0540242E-9*(9239-46264) +(CLOCK _COUNT)(CLOCKperiod)

ToF = -2us

The initial pulse occurred at 0.5us and the second pulse occurs at 2.5us, but if you notice including the extra TIME2 into the formula yields the time between the first STOP and the second STOP for a total of -2us. If you wanted the total time for TIME2 (from START to STOP2) then you would need to remove the usage of TIME1 in the equation along with the subtraction.

To answer your question the measurements are not that jumpy on my end, they vary a slight but for example doing the 0.5us test I would read anywhere from 9232-9243 for the TIME1.

For the dataset you can provide the same information like I provided above but for a bad reading to see if I can calculate this with you. I am not certain if the one you provided previously was a failed reading or not but it looks valid on my end. Also provide what your expected ToF result should be so that I can compare the answers.

I hope the example I just covered helps!

Best,

Isaac

Hi Isaac,

The calculation example you gave is at my humble opinion for the mode 1 while I set the TDC's here in mode 2 with a 16 MHz clock!

I will try to run in mode1 -although the data sheet do not recommend it for measurements above 500 ns- and see what is happening than.

The example calculations I based my program on is the following (page 18) in the datasheet:

100ns width - 500 ns distance - no T2 - faulty
StatusTdc2	00011001	
StatusTdc1	00011001	
Time1Tdc1	454	
Time2Tdc1	1124	
Time1Tdc2	450	
Time2Tdc2	1040	
CalReg1Tdc1	1097	
CalReg2Tdc1	10948	
CalReg1Tdc2	1086	
CalReg2Tdc2	14899	
ClkCnt1Tdc1	15	
ClkCnt1Tdc2	23	
Result3		49.24218750000000000	

400ns width - 500 ns distance - no T2 - faulty				
StatusTdc2	00011001	
StatusTdc1	00011001	
Time1Tdc1	240	
Time2Tdc1	914	
Time1Tdc2	238	
Time2Tdc2	824	
CalReg1Tdc1	1097	
CalReg2Tdc1	10947	
CalReg1Tdc2	1087	
CalReg2Tdc2	14899	
ClkCnt1Tdc1	15	
ClkCnt1Tdc2	23	
Result3	49.60156250000000000	

400ns width - 500 ns distance - with T2 - faulty		
StatusTdc2	00011001	
StatusTdc1	00011001	
Time1Tdc1	436	
Time2Tdc1	1111	
Time1Tdc2	432	
Time2Tdc2	1024	
CalReg1Tdc1	1100	
CalReg2Tdc1	10972	
CalReg1Tdc2	1089	
CalReg2Tdc2	14899	
ClkCnt1Tdc1	15	
ClkCnt1Tdc2	23	
Result3	8388552.953125000000	

400ns width - 500 ns distance - with T2 - faulty	
StatusTdc2	00011001	
StatusTdc1	00011001	
Time1Tdc1	212	
Time2Tdc1	884	
Time1Tdc2	210	
Time2Tdc2	806	
CalReg1Tdc1	1098	
CalReg2Tdc1	10958	
CalReg1Tdc2	1088	
CalReg2Tdc2	14899	
ClkCnt1Tdc1	15	
ClkCnt1Tdc2	23	
Result3		8388552.449218750000	

400ns width - 500 ns distance - with T2 - correct
StatusTdc2	00011001	
StatusTdc1	00011001	
Time1Tdc1	719	
Time2Tdc1	297	
Time1Tdc2	712	
Time2Tdc2	216	
CalReg1Tdc1	1098	
CalReg2Tdc1	10953	
CalReg1Tdc2	1088	
CalReg2Tdc2	14899	
ClkCnt1Tdc1	14	
ClkCnt1Tdc2	22	
Result3		49.61328125000000000	
				

Hello Hans,

Thanks for providing the data. Perhaps my formula worked because I am using a 8MHz clock so the division are not as fine as yours, so I was not reaching any clock counts due to the longer clock periods. Perhaps I might retry it with a longer time or a faster clock to match what you are getting on your end. One quick note is that clock period for a 16MHz clock is 62.5ns not us I am not sure if this affecting your calculations. You did not denote the SI prefix for your results so they could be off by a couple of factors of 10 if you are using microseconds in your calculations.

I calculated all the info provided and I got approximately the 500ns for every calculation using the datasheet calculation on page 18. I am not sure if you are missing something in your program that is causing the calculations to be incorrect at times, such as examples 3 and 4.

One question I had is that you noted the first two calculation as faulty even though the value is the same as the last calculation  which you denoted as correct, so I am just a little confused as to why these are labeled as incorrect. I attached an excel sheet where I calculated the third result where your program generated the result of: 8388552.449218750000 and my calculation (based on the values provided) generated 514ns.

TDC7200 Calculations.xlsx

Best,

Isaac

Hi Isaac,

The 62.5ns is indeed scaled to 6.25 sec in order to have a better scaling when calculating  the result in fixed point arithmetic.  As all calculations are unsigned only it explains why the wrongly results are way out of the 500 ns time difference but I'll revise my calculations to cope with these situations and look if the results are more consistent.

I also noted that changing CALIBRATION2_PERIODS to 20 the flag MEAS_COMPLETE_FLAG is never set...

Groeten,

Hans

Hello Hans,

Got it thanks for the information! Let me know if any more help is needed on the calculations.

On the CALIBRATION2_PERIODS remark, I haven't observed this behavior before so I would need to test this out to confirm if this is the case.

Best,

Isaac

Hello Isaac,

I changed all calculations to signed what sees to have solved the problemo of the calculations.  Did you had time to look into the CALIBRATION2_PERIODS behaviour?

Yet another question:can you elaborate the sentence in the data sheet a little more as I don't understand how the chip it :