Undocumented Feature ? Digital Filters

[Frank B]

Hi..

maybe i've found a new undocumented feature.. i don't know how to test it, because i don't have the technical equipment.

Example, for Port D:
#define PORTD_DFER (*(volatile uint32_t *)0x4004C0C0) // Digital Filter Enable Register
#define PORTD_DFCR (*(volatile uint32_t *)0x4004C0C4) // Digital Filter Clock Register
#define PORTD_DFWR (*(volatile uint32_t *)0x4004C0C8) // Digital Filter Width Register

See description in http://cache.freescale.com/files/mic...n&fileExt=.pdf (a different chip) These registers were added 2014 to this document and were not describd before.

We have a short note in "5.7.4 PORT digital filter clocking" in "our" refmanual too, but the rest is missing.

The registers are readable and writeable on the teensy3.1
It would be great if someone could test if the filters work !!

[PaulStoffregen]

That is really interesting indeed....

[Frank B]

They seem to do "something"..
When i write "1" to these registers, my parallel-sd-reader (which needs really fast inputs) does not work anymore

[MuShoo]

Quoting some relevant seeming stuff from that document:

The digital filter capabilities of the PORT module are available in all digital Pin Muxing
modes if the PORT module is enabled.

The clock used for all digital filters within one port can be configured between the bus
clock or the 1-kHz LPO clock. This selection must be changed only when all digital
filters for that port are disabled. If the digital filters for a port are configured to use the
bus clock, then the digital filters are bypassed for the duration of Stop mode. While the
digital filters are bypassed, the output of each digital filter always equals the input pin,
but the internal state of the digital filters remains static and does not update due to any
change on the input pin.

The filter width in clock size is the same for all enabled digital filters within one port and
must be changed only when all digital filters for that port are disabled.

The output of each digital filter is logic zero after system reset and whenever a digital
filter is disabled. After a digital filter is enabled, the input is synchronized to the filter
clock, either the bus clock or the 1-kHz LPO clock. If the synchronized input and the
output of the digital filter remain different for a number of filter clock cycles equal to the
filter width register configuration, then the output of the digital filter updates to equal the
synchronized filter input.

The minimum latency through a digital filter equals two or three filter clock cycles plus
the filter width configuration register.

Now, most of this doesn't make much sense to me. The way I understand it is that it'll essentially only update those pins' states at every 'filter clock' cycle, which can be made to be slower than the usual clock cycle? Basically a synchronization thing?

*Edit: Wait wait, could this be used for hardware debouncing? There's talk of it 'absorbing glitches' elsewhere in the manual.

[Frank B]

Yes, i don't know if the archivable "debounce" time is long enough for switches, buts that's the point.
In addition, sometimes signals are "noisy", and you can filter this noise.
But i'm not that expert in electronics, I'm sure other users can explain it better.

Edit:
From my little unprofessional test (at a first glance) this feature seems to work (?)

[alpage]

I've been testing this feature to debounce some CNC limit switches. Using Teensy 3.5 and switches connected to Port D pins. (According to documentation, only Port D pins support digital filtering)
Logic analyzer screenshots are on https://imgur.com/a/m7ry8.

I used the 1 kHz LPO clock for the filter and set the filter width at 8 cycles. This results in about a 10 millisecond delay while the filter waits for a valid transition. Interestingly, both edges of the signal are delayed, even though releasing the switch seems to result in a clean signal edge with no glitches. It will work very well for the intended purpose. Generally the limit switch is approached at fairly high speed, say 500 mm/min. With a 10 millisecond delay that works out to about .08 mm or about .00315 inches. After hitting the limit switch the pull-off is generally much slower, for example 25 mm/min. That works out to about .000417 mm per millisecond or .000164 inches per millisecond. Even if the digital filter delay varies by a couple of milliseconds, the resulting 'error' is insignificant.

The code is quite simple.
#define LIMIT_X_PORT_BIT (1<<4) // e.g. for D4 (pin 6 on Teensy 3.5)
PORTD_DFER = 0; // disable digital filter when changing settings, Generally done once in setup.
PORTD_DFCR = LIMIT_X_PORT_BIT; // set clock to 1 kHz LPO
PORTD_DFWR = 0x08; // 8 milliseconds.
PORTD_DFER = LIMIT_X_PORT_BIT; // enable digital filtering.

Of course if you are doing a lot of digital filtering or turning them on and off you need to twiddle the bits more carefully.

[Frank B]

I've been testing this feature to debounce some CNC limit switches. Using Teensy 3.5 and switches connected to Port D pins. (According to documentation, only Port D pins support digital filtering)

Anyone tried that on a T3.2? I was never curious enough to check if this actually works on a T3.2.

[alpage]

Results on a 3.2 were confusing. I was using a probe pin connected to pin 14 which is Port D1. The enable and control port values should have been 2, but that didn't work. For reasons I can't explain, PORTD_DFCR = 1 worked but PORTD_DFER must be 2 (as expected). Perhaps because this is undocumented they don't check this feature on those chips. Would only know after further testing, best done by Paul (if he's interested) because he has a large supply of Teensy 3.2's to see if it works the same way on all of them. Ideally test all the Port D pins with all possible bits set and cleared in the control and enable registers.