Strange timer behavior in an XC-2

[jarnot]

I have written a simple test program that does not behave as I would expect. One thread on core 1 generates a 12.5 kHz square wave on port 1D. This signal is monitored by another thread on core 1 (via port 1A), which counts the number of cycles of the signal in ~1 second, and prints the result for diagnostic purposes. The first time though the loop results in the correct result (12500). Every subsequent loop results in a significantly larger number, and putting a scope on the 1D-1A connection shows that the while loop in PutVFCsignal is alternately generating the expected 12.5 kHz signal an a very much faster one (10's of MHz). I have tried the code on two XC-2s and observe the same behaviour, so I suspect that I have a coding error.

Commenting out the two lines which start with "VFCin when pinseq ..." in GetVFCcounts results in a stable 12.5 kHz signal. Can anyone point out what I am doing incorrectly that allows the two threads to interact in this unwanted manner? I have included the file VFCtest.xc as an attachment, but my lack of expertise at using a web interface like this means that I am not sure how this posting is going to appear.

[Bianco]

Hello Jarno,

I observe an 125KHz signal (8uS period).
I measured the faster frequency around 2.1MHz (on a 40 megasample scope).

The problems are caused by your print statements that use JTAG to print it on your host computer.
I don't know why there are timing problems AFTER you return from your print statements and also why the wrong frequency is faster.

Adding a delay after your print statements fixes it for me.

Code: Select all

VFCtimer :> t;
VFCtimer when timerafter(t+5000000) :> void;

[jarnot]

Hello Bianco,

Thanks for this information -- I don't think that I would have determined that the print statements were the problem for quite a while. I have modified the code to use a case statement which allows me to measure several VFC signals simultaneously on a multi-bit port, and to do so very conveniently (another example of how the XMOS architecture and software simplifies designs in a very satisfying way). My next step is to build up a packet of VFC data, and then output it via UDP, which should eliminate the strange behaviour.

Thanks again,

Robert Jarnot