Can FlexPWM inputs be configured to have HYS (schmitt trigger)?

[joepasquariello]

Background is I'm working on a project where Teensy 4.1 is plugged into a socket on a custom PCB. Two low-res tachometer signals are input to two FlexPWM channels (pins 6,9) with an instance of FreqMeasureMulti for each. The input circuit on the custom PCB results in slow rise times to the Teensy pins. Originally the rise time was very slow (150 us), and a resistor was changed to reduce rise time to ~15 us. Even with 15-us rise time, a single edge into FlexPWM channel can result in multiple triggers. We have worked around the problem for now by configuring the pins as GPIO (INPUT_PULLUP), which adds both 47K pull-up and a schmitt trigger, and we now get only 1 interrupt per edge, but we don't have the advantage of the input capture in hardware.

Is it possible to configure T4.1 to include the pull-up and schmitt trigger in the input circuit for FlexPWM?

I searched cores\Teensy4 and found that PUE/PUS/HYS flags are used for GPIO inputs as a function of the argument to pinMode(), and always for HardwareSerial RX pins. I see some things in the IOMUX chapters of the processor manual to think it might be possible to enable these features for other inputs.

 

[jmarsh]

The PAD control registers (where hysteresis, pull-up/downs etc are configured) are completely separate from the mux settings (which determines which module the pin is routed to), so I don't see why this wouldn't work. I can say I've definitely configured pins to use pull-ups/pull-downs/open-drain mode while not functioning as GPIOs without any issues.
The "*(portControlRegister(X))" macro is pretty handy for accessing the pin PAD control registers without having to wade through the docs finding which pin maps to which pad/registers.

 

[joepasquariello]

Thanks. I have never delved into the pin configurations, but for this one case I have looked at the code in function pinMode() in digital.c and the configuration table in FreqMeasureMultiIMXRT.cpp/h. The table in FreqMeasureMulti contains a value for the mux register, but not for the pad register, and I don't see anything being written to a pad register in FreqMeasureMulti::begin(). Do you think if I set pin 6 as GPIO INPUT_PULLUP, then for FreqMeasureMulti, the pad configuration set via pinMode() will remain? I can try it tomorrow.

 

[jmarsh]

Any pad register settings will stay active independent of the mux setting.

 

[joepasquariello]

Any pad register settings will stay active independent of the mux setting.

Thanks very much for this definitive statement. I tried it this morning and confirmed that if I call pinMode(6, INPUT_PULLUP) before calling FreqMeasureMulti's begin(6), that solves 99% of the noise issue. Throughout my software development process, all of the speed measurement testing was by jumpering PWM outputs from unused pins to use as simulated tach signals. Those PWM signals have very fast rise time, so the speed measurements were always perfect. As soon as we tried with a real tach signal going through the custom PCB to the Teensy, we found that our measured speed was very noisy. Now I understand that we need to be concerned with pad settings for each Teensy pin as a function of how we use the pin and the input circuit characteristics.

 

[MarkT]

Digital inputs require fast edges or they can oscillate and generate pulse swarms, and consume excess power - analog signals should go through a comparator to sharpen up the edges - for a fast chip you probably need rise and fall times better than 50ns for good behaviour, so quite a fast comparator is required, LM339 or better, with a stiff pullup (330 ohms?)

Sometimes a 74XX14 can do the job, as it has a decent amount of real hysteresis, for 3.3V use the 74LVC14 is probably best (faster than a 74HC14).

Do you have a fast 'scope as that would be invaluable for diagnosis.

 

[joepasquariello]

Digital inputs require fast edges or they can oscillate and generate pulse swarms, and consume excess power - analog signals should go through a comparator to sharpen up the edges - for a fast chip you probably need rise and fall times better than 50ns for good behaviour, so quite a fast comparator is required, LM339 or better, with a stiff pullup (330 ohms?)

Sometimes a 74XX14 can do the job, as it has a decent amount of real hysteresis, for 3.3V use the 74LVC14 is probably best (faster than a 74HC14).

Do you have a fast 'scope as that would be invaluable for diagnosis.

I have a logic analyzer, but no scope. The hardware design is out of my scope and expertise, though I do try to learn and understand as much as possible. I must be learning something, because I understand most of your post.

Can you comment on when it might be sufficient to rely on the internal hysteresis (schmitt trigger) built into the iMXRT versus ensuring that the signal has 50 ns rise time at the pin? This is still in flux, but we seem to be getting good results by doing two things, lowering the pull-up resistor on the board from 10K to 1K and enabling hysteresis on the pad. In limited bench testing, those changes seem to be enough to avoid multiple triggers, though we also have tested the addition of an external schmitt trigger to the board, which gets us to about 50 ns rise time and clean measurements even without enabling hysteresis on the pad.