Electronic – Nanosecond interrupt accuracy on a 64MHz microprocessor

clock-speedinterruptsmicrocontrollertimer

I am currently designing a PCB with a 64MHz nRF52832 bluetooth MCU. I have an interrupt connected to this MCU which needs to be detected with 1-3 nanosecond accuracy.

Unfortunately, the 64MHz MCU has a clock cycle of 15.625ns, meaning the interrupt could be recognized up to 15.625ns late (assuming zero interrupt latency for now). Please note that the interrupt does not need to be acted upon straight away, I only need to know at which time it arrived.

Is there any way for me to use external circuitry to improve my accuracy? I've considered using an external nanosecond timer to measure the offset, and sending that to the MCU every time the interrupt is triggered. Unfortunately, I'm having a hard time finding any timers that can run at this speed.

I am capable of changing the MCU to a faster processor, however nothing greater than ~180MHz – which would still be 5.56ns per clock cycle. For this reason, a creative external solution would be ideal.

Best Answer

Theoretical considerations

For a digitizing system to detect something with a temporal resolution of \$\Delta t\$, it needs to have a sample rate of at least \$\frac2{\Delta t}\$. That's a corollary of Nyquist's sampling theorem.

In your case, this means that whatever pin might cause an interrupt that somehow notes the time the signal edge happened, you'd need some sampling clock (or, more precisely related to your application: a counter that can be latched on the external signal) running at least at 666.67 MHz.

practical considerations

Nothing short of that will do, unless you can build an external system that somehow converts the event into something slower that can then be observed afterwards to calculate the time it happened.

So, what I'd propose is actually the approach you've been recommended in the comments, namely, using high-speed counter e.g. inside an FPGA to capture the time and read it whenever you're ready with your MCU.

Or, you use the impulse and very fast analog electronics to e.g. kick of e.g. an exponential voltage decay which you can periodically observe and extrapolate from the observed rate of decay the point in time when it got started. That way, you'd actually be trading ADC resolution (interrupt pin: "1 bit ADC", if you want so) for timing resolution. You'd still need a pretty good ADC and accompanying CPU speed.

In the end, your problem is a hard one, as detecting nanosecond precision pulses is a hard problem – even starting from a PCB layout point of view (the quality of your pulse edge is a function of the signal bandwidth you can transport on your PCB trace – and for a signal with 1/(1ns) = 1 GHz fundamental frequency, this already becomes non-trivial).

You'll probably either need a very fast FPGA, or aforementioned analog time-to-function converter, a moderately fast ADC and a moderately fast FPGA to deal with the ADC data.

scratch that.

I just read up on time-to-digital converters. Maxim (e.g. MAX35102) and TI offer such (other company certainly, too).

As far as I read this, there's different approaches, but the TI TDC7200, for example, uses an internal ring oscillator (which runs at pretty high speeds, giving you high resolution) to run a counter.

The ring oscillator is disciplined against an external clock, so you'll have to make sure your accuracy needs are met by the quality of that clock.

Related Solutions

Electronic – Measuring 0 – 1MHz ( 0.25Hz resolution) Squarewave using an MCU

If possible I'd suggest selecting a microcontroller that supports a counter operation using the timer inputs; rather than manually incrementing a counter inside an ISR (which at high frequencies quickly ends up saturating the microcontroller activity) you allow the hardware to handle the counting. At this point your code simply becomes a matter of waiting for your periodic interrupt then calculating the frequency.

To extend the range and make the frequency counter more generalised (removing the need for multiple ranges at the expense of a little more work for the MCU) you could use the following technique.

Select a periodic interrupt rate that allows for measurement accuracy at the highest input frequency; this should take into account your counter size (you need to select the timer period such that the timer counter will not overflow at the maximum input frequency). For this example I'll assume that the input counter value can be read from the variable "timer_input_ctr".

Include a variable for counting periodic interrupts (should be initialised to 0 at startup); for this example I'll refer to this variable as "isr_count". The interrupt period is contained in the constant "isr_period".

Your periodic interrupt should be implemented as (C pseudo-code):

void timer_isr()
{
  isr_count++;
  if (timer_input_ctr > 0)
  {
    frequency = timer_input_ctr / (isr_count * isr_period).
    timer_input_ctr = 0;
    isr_count = 0;
  }
}

Obviously this rough example relies on some floating point math that may not be compatible for low-end microcontrollers, there are techniques to overcome this but they are outside of the scope of this answer.

Independent watchdog (IWDG) or Window watchdog (WWDG)

Regular watchdog timers must be reset at some time before they time out. If you have a 100ms WDT you can reset it every 99.9ms or every 10us and it will never time out.

Window watchdog timers have a time window within which they must be reset. If you reset it too early or too late (from the previous reset) it will cause the processor to reset.

The purpose, if it is not obvious, is to help ensure that the code resetting the WDT is the intended code, operating in the intended fashion. Some kind of unforeseen condition that generates high-frequency WDT resets won't prevent the system from being reset.

Running a WDT from the system clock could be a bit of an issue- if the clock fails and if there is not an independent clock monitor circuit, bad things can happen. The independent clock for the WDT means that if the thing for some reason started running at 1/10 speed, the WDT would reset (but the window WDT would not).

Use both if you can.

As the page says, resetting the WDT with an ISR is generally bad juju (but may be acceptable if the ISR verifies the reset of the firmware is functioning before resetting the timer).