Teensy 3.5 5v tolerant for CMP

Status
Not open for further replies.

TelephoneBill

Well-known member
I would like to experiment with the Teensy 3.5 comparators.

I know that Teensy 3.5 has 5 volt tolerance on digital pins. Does this also apply if I map a comparator input to for example Port C6 (Teensy Pin 11)?

I'm wondering what the issue is about 5v tolerance - is this only if a pin is in digital mode and is not the case for the internal analogue circuitry (such as comparators and ADC)? The signal I'm looking at sometimes peaks around 4 volts.
 
I'm afraid to report BAD NEWS... (using CMP1 and not CMP0 here, so Pin 23 instead of Pin 11)...

(1) I did a simple experiment first on CMP1. I put a 10 turn 10K pot across 3.3v and GND and fed the wiper (at 0 volts) to Pin 23. I set the comparator to use INP(0) on Pin 23, and INM(7) to use the enabled the 6 bit DAC using VREF2 (Vdd). Resistor ladder network was set to midway threshold (about 1.666 volts). No filter count and zero hysteresis setting. Comparator output direct to Pin 10 (no window or filter). I monitored CMP0 (COUTA) with a scope probe on Pin 10 and a digital voltmeter (to watch the actual output voltage), and tested bit 0 of the CMP1 status register in the program loop code to put the Pin 13 LED either on or off accordingly.

Good results. The scope showed logic '0' on the output initially. As I slowly wound the pot clockwise to increase the wiper towards the midpoint, I noticed at a voltage of 1.648 volts that short bursts of oscillation took place as I entered the threshold region of the comparator. These bursts became "longer/more frequent" as I climbed through 1.650 to 1.680 and the output on scope then flipped to logic '1' without oscillation at a voltage of 1.695 volts. During this climb through threshold, the Pin 13 LED was showing dim at first becoming brighter (in accordance with the length of oscillation bursts) till fully lit.

This behaviour was consistent in the reverse downward descent of wiper voltage (with minor hysteresis). Going back up again it behaved the same. I did this test several times up and down.

(2) On reading your reply, I then decided to do the next experiment of replacing the 10 turn wiper on Pin 28 with my d.c. 100 KHz sinsusoid test signal. This had a mean d.c. level of 2.4 volts and +/- 1.6 volts amplitude sine wave, so the maximum voltage was about 4.0 volts and minimum about 0.8 volts.

This did not get the clean threshold square wave on the scope that I had expected. When the signal went above threshold, then logic '1' was clean. But when the amplitude dropped below threshold, all I could see was oscillation where it should have been logic '0'. It remained in this state for a few minutes. The INM threshold was still around midpoint of Vdd at 1.666 volts (not changed).

(3) I then decided to repeat the experiment (1) again, using only using the 10 turn pot on Pin 23. Now the behaviour was quite different. It looked as though the threshold hysteresis levels had been damaged. The comparator still worked well above or well below threshold, but instead of a switch of logic levels between 1.648 and 1.695 volts, the hysteresis gap was much wider. It took until about 1.790 volts to get the comparator to switch to logic '1', and I had to descend to 1.590 volts to get the complete switch to logic '0'. This behaviour was also noticed on the Pin 13 LED. No longer was there a gradual change from dim to fully lit when traversing the threshold region, but the oscillation bursts seen on scope disappeared and replaced with a continuous oscillation.

Despite several attempts to reproduce the initial results of (1), it would not go back to the original behaviour. It looks like some small damage has taken place to the comparator circuitry, whereby the hysteresis mechanism has been altered/corrupted.

===

FORTUNATELY - I have another identical unused Teensy 3.5 bought at the same time. So the job tonight will be to solder some pins on this second board and repeat experiment (1) with this second board, and see if it maintains the same original behaviour (without exceeding 3.3 volts on input Pin 23) as seen on the first board.

I will feed back my findings.
 
A few hours later. Have now done some tests on the second Teensy 3.5 board.

Hmm... not quite straightforward. Put it into the same breadboard circuit as the first one, and at first showing it was behaving same as in (2) with oscillation but only used the 10 turn pot at voltages around 1.5 to 1.7 volts (never higher).

Then unexpectedly I noticed a big change. Suddenly the second board had no oscillations at all during the threshold transition, and I was getting either logic '0' or logic '1' clean swift transitions in place, as seen on the scope as the wiper voltage went from 1.664v to 1.669v. Puzzled, I then noticed a construction error - the scope was actually on a different (more indirect) earth path to the 10 turn pot. It is possible that earth noise has been influencing findings (we are talking a few millivolts for the threshold transition).

I'll do some more tests on the first board tomorrow (Sunday) with a better earth arrangement. Perhaps it is not altered/damaged after all? Fingers crossed...
 
GOOD NEWS to report this morning... in fact, EXCELLENT NEWS as it turns out...

Bad "Grounding" WAS the cause of trouble. Both boards now perform the same, and in fact exceedingly well, far better than I could have wished for. The initial performance in experiment (1) above was itself spurious and once the grounding had been rectified I got the following remarkable results...

At precisely 1.662 volts the threshold transition of the output from logic '0' (GND) began. At 1.663 volts it was complete and solid to logic '1' (Vdd). The threshold "gap" was a mere 1 milliVolt and no oscillation as before, only a "slow jitter" between the levels as I increased the pot wiper through 1.662 to 1.663 volts.

To see a comparator perform this well at 1 mV hysteresis is truly amazing.

The lesson (for me) in this tale is "beware of grounding/earthing" noise spikes when using a precision comparator in the mixed analogue/digital world :)
 
Finally, here is an interesting application of the Teensy 3.5 comparator (CMP1). Its the detection of a LORAN C radio signal (see my previous work elsewhere in the forum). This signal is brief bursts of precision 100 KHz in groups of 8 bursts spaced at intervals of 67,310 uS. The signal has a special wave shape as it emerges from the background noise to grow to about 7 cycles before decaying. Its feature is to arrive faster as a direct ground wave, before the ionosphere's reflections arrive (which then distort the signal phase). You can then extract precise timing (around the 7th cycle) with respect to national time standards.

LoranCompare01.jpg
 
I believe this is the first time that the CMP is shown to be working. Would you please share a code snippet to show us what you did?
 
Not the first time - I copied this code from elsewhere (can't remember where), which was an example of threshold of a small 200 mV peak 10 MHz signal.

I'm only working at 100 KHz. Here is my snippet.

Code:
  //Enable CMP1 to threshold radio receiver output - Teensy 3.5
  //===========================================================
  //output is on Teensy pin 10 (Port C4)
  //input is Teensy pin 23 (Port C2, also called pin A9)
  //voltage reference (INM7) is 6-bit internal DAC, VIN2 = VDD (3.3 volts)
  //comparator output state available - read least sig bit of CMP1_SCR

  #define CMP_MUX_PSEL(n)    ((uint32_t)(((n) & 0b111) << 3))   // Plus Input Mux CMP Control
  #define CMP_MUX_MSEL(n)    ((uint32_t)(((n) & 0b111) << 0))   // Minus Input Mux CMP Control
  
  SIM_SCGC4 |= SIM_SCGC4_CMP; //Clock to Comparator
  CORE_PIN10_CONFIG = PORT_PCR_MUX(6); //Alternate function 6: Teensy pin10 = CMP1_OUT, PTC4
  CMP1_CR0 = 0b00000000; // FILTER_CNT=0; HYSTCTR=0
  CMP1_CR1 = 0b00010111; // SE=0, high power, COUTA, output pin, enable; mode #2A
  CMP1_DACCR = 0b11011111; //Set DAC = 1/2 of VIN2 (3.3v) 
  CMP1_MUXCR = CMP_MUX_PSEL(0) | CMP_MUX_MSEL(7); // Input pins select; plus = IN0 (pin 23), minus = DAC (code 7). PSTM = 0 (Pass Through Mode Disabled)

In the end I didn't need 5v tolerance explicitly. By A.C. coupling the signal with a 0.1 uF capacitor to input, this removed the D.C. content and lowered the max voltage. I also kept the 10 turn pot wiper (still across Vdd and GND) so that I could bias pin 23 to a midpoint D.C. voltage and get a 50/50 mark/space ratio (also keeps the pin within the 0 to 3.3 volt range, providing the A.C. signal peak is not too big) . You could use fixed resistors of course to do the same job.

The secret to success was setting the clock in the SIM_SCGC4 register. This is not mentioned in Chapter 36 (page 879) of the reference manual. If this is omitted then Teensy will lock up. I'm not using either the filter or the window features, just a straight connection to the comparator output, but the clock is still important.

Works really well. Very pleased. I think the propagation delay at high power mode is only 50 nS so I'm going to try experiment on a 10 MHz sine OCXO, which is often a low voltage signal. Will need the bias pot/resistors to cope with a negative going sine wave and place this in 0 to 3.3v range of pin 23.
 
The secret to success was setting the clock in the SIM_SCGC4 register. This is not mentioned in Chapter 36 (page 879) of the reference manual. If this is omitted then Teensy will lock up. I'm not using either the filter or the window features, just a straight connection to the comparator output, but the clock is still important.

This is not only true and important for the comparators but for ALL internal peripherals (DACs, ADCs, SPI, I2C, I2S, UARTS, USB, and so on) which are by default disabled on boot to save energy. Each single peripheral must be activated in the clock distribution module before accessing its registers. If not, read/write accesses will go into the Nirwana and the Teensy will hang with a hard fault. Fortunately, the most used peripherals are enabled either through Paul's Teensyduino startup code, or during class initialization (i.e. Serial.begin()), so that you wouldn't have to care about that.
 
@TelephoneBill Thank you for the code snippet.

@Thgeremingenier Thank you for the finer detail.


I'm adding this post to my reference list in hopes it provides a helpful pointer in the future.
 
Status
Not open for further replies.
Back
Top