TDC7201: Calibration calculations result in 14 nanosecond resolution, not sub-100 picoseconds

The particular area I would like help with is understanding what may be causing the calCount to be so low. Or might I be miscalculating it? Happy to provide other register settings if needed but I'm not doing much different to the register power-on default values, save for the 20 calibration periods already mentioned.

Hello Simon,

Thanks for posting to the sensors forum!

The calibration values seem rather small to me, for example I ran a 20 calibration periods measurement on one of the EVMs I have here and I got the following results:

CALIBRATION2- 46,376 (decimal)

CALIBRATION1- 2320 (decimal)

calCount- 2318.74

normLSB- 53.9 picoseconds (8MHz reference clock)

The calCount number is very small which makes your normLSB number very large. The calibration registers are 24 bit registers, can you confirm if you are reading this entire number and not just a portion of it?

Best,

Isaac

Hi Isaac, thanks for trying to reproduce a similar setup. Did the hardware schematic look reasonable to you for starters? I had wondered about the ability of my driver to successfully read a 24 bit register, as opposed to the 8 bit config/interrupt registers. However, I set my stop mask HIGH register to 0x1, which resulted in a TIMEn that was greater than 0xFF, so I think I have managed my driver to successfully read 3 bytes from all registers with address value greater than 0x9.  Any other ideas for things to check next, or a different check to perform to confirm I'm successfully reading 24 bits?

Hello Simon,

The schematic should be fine, I didn't see anything critical on there that should be changed . The only comment I have from an applications standpoint is that we typically don't recommend using the TDC7201 with free running clocks for the START and STOP signals. Although, I have had other users successfully use it this way before, the reason we dont recommended is that never validated the behavior of the internal digital logic in the scenarios where a device is receiving a START or STOP signals while its in other states of the state machine. 

Simon Merrett said:

I think I have managed my driver to successfully read 3 bytes from all registers with address value greater than 0x9

That's good to hear, that is the main test I would have done on my end since the TIME_x registers are easier to control in order to generate a larger value.

1. Did this SPI change make any difference to your CALIBRATIONx registers?

2. Have you tried performing just a single measurement with a known time difference to see what your calibration results look like? I don't think this will make a difference but it would be a good sanity check to make sure we can rule this out as an issue.

3. What are you using as a clock source for TDC_CLOCK?

Best,

Isaac

Hi Isaac, thanks for the reply.

Isaac Lara said:

1. Did this SPI change make any difference to your CALIBRATIONx registers?

Sorry, my answer was implied and I should have been explicit: no, the CALIBRATIONx registers did not appear to change when I added the stop mask and printed out all registers after completing the measurement.

Isaac Lara said:

2. Have you tried performing just a single measurement with a known time difference to see what your calibration results look like? I don't think this will make a difference but it would be a good sanity check to make sure we can rule this out as an issue.

I haven't although I don't have access to the signals to be able to remove the stop clock and inject a single pulse - too deeply integrated in this version. I may be able to recreate something on the EVK though.

Isaac Lara said:

3. What are you using as a clock source for TDC_CLOCK?

A single ended LVCMOS 3.3V square wave from a SiTime clock generator IC, at 10 MHz, 50% duty. It is not the same clock as the STOP signal.

Hey Simon,

No worries I figured you had checked if it made a difference but thought I would double check just in case.

I think it would be interesting to test a similar use case in the EVM to see what you are seeing on there. The main thing I am interested in is actually the clock, since the calibration is performed using the reference clock I am curious to figure out if its your clock that is presenting the issue. We have a clock considerations section on the datasheet have you taken a look at this list yet to see if your current 10MHz clock meets some of these guidelines?\

You can read them at section 8.3 of the datasheet. Here is a snippet of that section:

Have you tried reducing the amount of calibration cycles to see what kind of effect it has on your measurement?

Best,

Isaac

Isaac Lara said:

have you taken a look at this list yet to see if your current 10MHz clock meets some of these guidelines?

I hadn't looked because I was confident I had a pretty good clock. The accuracy and jitter specs are better than the figures in the example calculations in that section, so I don't think that those factors are contributing significantly.

Isaac Lara said:

Have you tried reducing the amount of calibration cycles to see what kind of effect it has on your measurement?

Yes. Initially I tried the 10 and 2 cycle settings but the calCount is still around 6.95 - 7.0.

I will try and set up an EVK with similar START and STOP signals, although I can't be sure they will 100% represent what is on the integrated board because the layout and transmission routes are obviously different.

Hello Simon,

That's good to hear I wanted to ensure we reviewed the clock specifications to ensure that it was good for this application.

Simon Merrett said:

I will try and set up an EVK with similar START and STOP signals, although I can't be sure they will 100% represent what is on the integrated board because the layout and transmission routes are obviously different.

I think the evaluation kit will help us determine if its a routing, device, or clock issue. If there is any way you could jumper the direct signals you have on your integrated board then that would be extremely helpful. But once you get a chance to test this please let me know what the outcome of your tests was.

Best,

Isaac

Hi Isaac, I have tried to replicate the issues I described above using the EVK. I first tried the 1Hz pulse into TDC1 START and a 10 MHz square wave into STOP, using the local/onboard 8MHz reference oscillator. This worked OK but not every time I requested a measurement through the GUI - TIMEn registers often read 0x0. When it did work I got sensible numbers for TIMEn and the calibration resolution looks sensible (~0.06 = 60 picoseconds). 

Then I moved to a higher speed clock for STOP that is the same as my application and also the same 10 MHz external reference input that I am using on my own board. This also produced sensible values but again, didn't reliably produce readings each time they were requested - it often showed no response in the post-measurement register values, as far as I could read on the GUI.

In summary, the behaviour was not perfect but I could not reproduce the issue described above. Please let me know what else could we look at.

Hello Simon,

Thanks for the update, I am not certain what kind of timeout window you had configured but its possible the no response scenarios may have been during scenario where the START pulse may not have occurred in time before a timeout. Its hard to say without any scope captures what happened in those scenarios.

I am not sure if this is a possibility for you but have you tried replacing the TDC device on your board with a new one? My concern is that perhaps it may have been damaged during installation.

Best,

Isaac

Hi Isaac, I'm not sure what the timeout window configuration refers to. From my understanding of reading the datasheet:

7.4.3 Timeout For one STOP, each TDCx of the TDC7201 performs the measurement by counting from the START signal to the STOP signal. If no STOP signal is received, either the Clock Counter or Coarse Counter will overflow and will generate an interrupt (see Coarse and Clock Counters Overflow). If no START signal is received, the timer waits indefinitely for a START signal to arrive

I understand that there will be no timeout prior to a START signal. Happy to be enlightened otherwise though.

However, from reading the next section down, I did see that multiple STOPs do have a minimum STOP-STOP time that is greater than my STOP clock period as I was planning on using this to help determine if a STOP had arrived prior to the initial 12 nanosecond window.

Isaac Lara said:

but have you tried replacing the TDC device on your board with a new one?

Just after I messaged you yesterday I tried to hot-air rework the chip in case I had solder connection issues. I was pretty unsuccessful at getting the package to come off, even though surrounding parts were swimming on top of molten solder, so the thermal sink around that part must be strong and could possibly have caused poor connections. I'm just wondering which connection could be causing that issue. Anyway, you may remember that I mentioned in my OP that I was

Simon Merrett said:

having some issues getting repeated readings from registers (after a short while, previously successful register readings return 0x0)

And after the hot air rework I have reliable repeated register reads without need for enable/reset between, so the rework has improved at least one aspect of the performance. The part is close to a dense patch of 0201 components and a few sensitive ICs so I don't want to crank the hot-air up too much.

Hey Simon,

Your understanding of the datasheet is correct, but the exception is that for the GUI a timeout was implemented to prevent the GUI from hanging and waiting for a measurement perpetually. I probably should have been more clear on that one when I mentioned it.

Simon Merrett said:

I did see that multiple STOPs do have a minimum STOP-STOP time that is greater than my STOP clock period as I was planning on using this to help determine if a STOP had arrived prior to the initial 12 nanosecond window.

Hmmm I am not sure if this 12ns window you have configured applies to the following STOPs after the initial one, this is not something I have looked into before. Are you currently setup to detect multiple STOPs or just a single STOP?

Simon Merrett said:

having some issues getting repeated readings from registers (after a short while, previously successful register readings return 0x0)

Yeah I do recall this, I guess we never discussed this since it seemed like you had found a workaround for this, but it sounds like you may have had some bad connections somewhere in your SPI lines. It makes me wonder if perhaps a bad connection from the clock to the TDC exists on your board creating some parasitic capacitance causing these bad calibration results.

I know you werent able to rework the current part but if you have an extra board it might be worth populating that one and see if a problem exists there. I am assuming you have a really good ground connection perhaps so sometimes I like to heat the board from the bottom to get it to a good temperature and then provide heat from the top to get the parts moving. Tends to work better with bigger ICs, smaller components like 0201s dont require so much work since its less copper you usually have to heat up.

Best,

Isaac

Hi Isaac, I found a problem with my rework - the power supply to my STOP clock had become disconnected. While doing the immediate testing after rework, before I found this, I was getting successful SPI reads of the config registers, repeatedly, with absolutely no need for an enable line reset between sequential reads. When I tried to carry out a new measurement, I got the COARSE_CNTR_OVF_INT firing, so that's what made me check if the STOP signal was present. When I then reworked the clock power supply, which has a known footprint issue and this caused a short when solder reflowed during the initial rework, to reinstate it, I started getting successful TIMEn values and associated interrupt register values but again lost the ability to read values from config registers without an En line reset between readings. This seems very strange to me. Why would the presence of the STOP signal, or its absence, make a difference to the ability to read register values?

Thanks for the suggestion about a hot plate underneath. Unfortunately the board is populated on both sides so that isn't an option. Do you have a recommendation as to whether solder paste should be used with this part? I assumed BGA would be fine with the ENIG finish and the rework involved plenty of no-clean tacky flux that usually does a good job but perhaps you recommend stencilling paste on pads as well in addition to the solder balls on the package?

Back to the firmware, I also implemented a STOP signal mask of LSB = 0xFF. This leads to multi-octet values in TIMEn but I get the same calibration register values as when I leave that blank. Here's an example output of register reads and calcs after the interrupt pin fires:

TDC7201 interrupt fired
Register 0x2    TDCx_INT_STATUS register value: 0x19
MEAS_COMPLETE_FLAG    MEAS_STARTED_FLAG    CLOCK_CNTR_OVF_INT    COARSE_CNTR_OVF_INT    NEW_MEAS_INT
    1            1            0            0            1
Clearing interrupt status bits
Address to write: 0x42
Register 0x2    
    0            0            0            0            0
Register 0x10    TDCx_TIME1 register value: 0x6F9
Register 0x11    TDCx_CLOCK_COUNT1 register value: 0x0
Register 0x12    TDCx_TIME2 register value: 0x6FD
Register 0x13    TDCx_CLOCK_COUNT2 register value: 0x0
Register 0x14    TDCx_TIME3 register value: 0x700
Register 0x15    TDCx_CLOCK_COUNT3 register value: 0x0
Register 0x16    TDCx_TIME4 register value: 0x704
Register 0x17    TDCx_CLOCK_COUNT4 register value: 0x0
Register 0x18    TDCx_TIME5 register value: 0x0
Register 0x19    TDCx_CLOCK_COUNT5 register value: 0x0
Register 0x1A    TDCx_TIME6 register value: 0x0
Register 0x1B    Register 0x1C    calCount: 7.00
normLsb: 14285.71
Register 0x1B    TDCx_CALIBRATION1 register value: 0x7
Register 0x1C    TDCx_CALIBRATION2 register value: 0x46
Register 0x0    TDCx_CONFIG1 register value: 0x0
Register 0x1    TDCx_CONFIG2 register value: 0x44
Register 0x3    TDCx_INT_MASK register value: 0x7
Register 0x4    TDCx_COARSE_CNTR_OVF_H register value: 0xFF
Register 0x5    TDCx_COARSE_CNTR_OVF_L register value: 0xFF
Register 0x6    TDCx_CLOCK_CNTR_OVF_H register value: 0xFF
Register 0x7    TDCx_CLOCK_CNTR_OVF_L register value: 0xFF
Register 0x8    TDCx_CLOCK_CNTR_STOP_MASK_H register value: 0x0
Register 0x9    TDCx_CLOCK_CNTR_STOP_MASK_L register value: 0xFF

You can see that the STOP readings are about 3 - 4 counts apart, which is approximately the 60 nanoseconds minimum and lines up with the expected count if the LSB is truly 14 nanoseconds. This suggests to me that the calibration LSB is being calculated correctly from correct calibration register reads. How do you interpret it?

Simon,

Isaac is currently out of office on personal timebank.  He should be back tomorrow.  In regards to the question about the solder flux, you can refer to this document for recommendations installing this package type:

https://www.ti.com/lit/ug/spru811a/spru811a.pdf

One caution to be mindful of when using flux is that all water-soluble flux residue should be removed afterwards.  

Thanks,

Scott

Thanks for letting me know to wait a little longer for Isaac and for the soldering reference. I brush/sluice with IPA usually.

Hello Simon,

Thanks for the patience, I just got back in the office so let me review your reply and get back to you.

Best,

Isaac

Hello Simon,

Good to know you were able to find the problem on the STOP clock and got it back to working condition!

Although I am still not sure why you would have to disable and enable the device in between reads. If you have a capture of what your SPI transaction looks like perhaps we may be able to find something there. Here is a capture of my SPI transaction for a register read. Please note that the logic analyzer denotes Enable but this is the chip select line. 

If you are running a 20MHz clock you should be seeing a STOP signals every 50ns, I am not sure if the 60ns from the comment above was a typo. Nonetheless the number does seem to lineup with the 3-4 counts apart so it does seem to track with your normLSB calculation in case if you were doubting the validity of the normLSB calculation I think this is pretty good proof that it is correct. Now the reason that your normLSB value is so large I have not been able to identify. You were not successful in replicating that with the EVM, do you have a second board that indicates this high normLSB value? I have not been able to create a large normLSB in my system.

Best,

Isaac

Isaac Lara said:

If you have a capture of what your SPI transaction looks like perhaps we may be able to find something there.

On this design we went pretty high density (for a dev board) and I don't think I can get the SPI lines out easily. Will keep that in reserve.

Isaac Lara said:

If you are running a 20MHz clock you should be seeing a STOP signals every 50ns, I am not sure if the 60ns from the comment above was a typo.

I'm running a 10 MHz reference clock and the STOP clock period also ties in with the LSB: if the LSB is ~14 nanoseconds, it will trigger on a multiple of 14, ie 28, 42 or 56 (plus a few counts for the LSB fraction over 14 nanoseconds). So I'm thinking it is only able to deal with the fourth subsequent STOP pulse after the first one is received, sort of lining up with the datasheet spec "Minimum time between 2 stop signals = 67 ns". Just a thought.

Isaac Lara said:

do you have a second board that indicates this high normLSB value

I spent yesterday building a second board and brought it up today. Unfortunately I'm getting very similar LSB readings around 14 nanoseconds on that new board too. I think we will have to develop a separate custom breakout in order to find what's going on here.

Hello Simon,

Simon Merrett said:

LSB is ~14 nanoseconds, it will trigger on a multiple of 14, ie 28, 42 or 56 (plus a few counts for the LSB fraction over 14 nanoseconds). So I'm thinking it is only able to deal with the fourth subsequent STOP pulse after the first one is received, sort of lining up with the datasheet spec "Minimum time between 2 stop signals = 67 ns". Just a thought.

Okay, yes that is correct. The measurements will be in increments of 14ns since that is the smallest LSB value you are able to get in your system.

Simon Merrett said:

I spent yesterday building a second board and brought it up today. Unfortunately I'm getting very similar LSB readings around 14 nanoseconds on that new board too. I think we will have to develop a separate custom breakout in order to find what's going on here.

Unfortunate that you were not able to see a difference, but I was somewhat expecting this. There must be something in your system that is causing this calibration value to be so large but as you mentioned its difficult to troubleshoot if the hardware is not in place to debug. Please let me know if there are any other questions in the meantime.

Best,

Isaac

Thanks for the info Simon! I am glad you were able to figure this out.

Let me know if you are able to figure out the hardware reset between measurements issue.

Best,

Isaac

Isaac, one thing which would have been helpful is the source code that runs on the EVK MSP430 development board. I searched and couldn't find it when setting out to write my own. I did see a post on the forums asking about it but I think there was confusion and the TI rep thought the user was asking for the GUI source code and that request was denied. If we can see the TI driver for the EVK that might have helped me avoid the mistakes in my own. Is it published and if not, could it be?

Yes, thanks - it was there!

Awesome thanks for confirming!

Best,

Isaac