I'm still working on my frequency counter, and noticed some strange issues with the TCPWM counter. It seems I cannot start / stop it properly via signals coming from the UDB cells (I'm using DFFs there). I also had problems gating the count signal via an AND gate.
See the attached project - it is basically self-contained, but needs a a Nokia 5110 connected (but it could be replaced by sending the results via a serial port).
This implements a reciprocal frequency counter. It uses two similar counters (with 24 bit period). They are started with the first falling edge of the input signal, and the the counter waits until the reference counter overflows for the first time. When this happens, the next falling edge of the input signal stops both counters. Then one can use the count values of the reference and the input counter to calculate the input frequency.
To start a measurement cycly, a control register is used which resets the DFFs and reloads the counters (by a '1' pulse).
Since the TCPWMs of PSoC6 do not have an enable signal (as there was in the PSoC4), I'm using the start and stop inputs. A rising flank on the enable signal (which comes from the 3-input AND) starts the counters, and the falling edge stops the counters. Also, the falling edge captures the current counter values.
What I observe is:
- even though the counters are stopped, they seem to count further - reading the current counter value, and comparing them with the captured value show differences (which should not be since the counters are stopped)
- I tried to counter that by gating the path from inclk to count of the input counter with an AND gate (using the enable signal). When doing so, the counter does not count at all.
- at certain low input frequencies, the input counter does not reload, but keeps its current value (which can be seen because the display shows the actual counter values, and input value just
- at other low input frequencies, the input counter overflows as soon as its started (which the code displays as 'frequency too high')
The last one is probably caused by the third one - but issues one to three are very puzzling. Especially number 2 - this is so simple that I think one cannot do anything wrong, yet it does not work.
I observer this behaviour regardless of the core the code is running. I have one version of that running on the M0, one with the M4 and one where the code is split. The latter one seems to be the worst, from what I have found out during debugging this seems to be because the delay between finishing one measurement and starting the next is the shortest here.
I also tried to reset the counters by using the _SetCounter() function, but this seems to completely break them.
Any idea what I'm doing wrong here?