Code ported from Teensy3.0 to 3.2 - now flakey

I have made some further investigation.

I am now using a Teensy3.5 to generate a sequence of 4us "read-data" pulses and some fake index pulses. See my posting in another thread about using DMA and the PIT timers to stream an 8-bit array to a 8-bit GPIO port.

I have connected the fake read-data and index pulses to the Teensy3.0. floppy disk read sketch. I am running some debug code which simply catches FTM timer values and displays them in a condensed histogram. I have programmed the FTM to run at 12MHz. Each 4us pulse should in theory result in a captured value of 48. I capture only 700 events(pulses), limited by available RAM on the Teensy3.1.

Code:
Total number of event captured 700
00000 _____ _____ _____ _____ _____ _____ 00001 _____ <- runt pulse value
00008 _____ _____ _____ _____ _____ _____ _____ _____
00016 _____ _____ _____ _____ _____ _____ _____ _____
00024 _____ _____ _____ _____ _____ _____ _____ _____
00032 ***** _____ _____ _____ _____ _____ _____ _____
00040 _____ _____ _____ _____ _____ _____ 00698 00001
00048 _____ _____ _____ _____ _____ _____ _____ _____
00056 _____ _____ _____ _____ ***** _____ _____ _____
00064 _____ _____ _____ _____ _____ _____ _____ _____
00072 _____ _____ _____ _____ _____ _____ _____ _____
00080 _____ _____ _____ _____ ***** _____ _____ _____
00088 _____ _____ _____ _____ _____ _____ _____ _____
00096 _____ _____ _____ _____ _____ _____ _____ _____
00104 _____ _____ _____ _____ _____ _____ _____ _____
00112 _____ _____ _____ _____ _____ _____ _____ _____
00120 _____ _____ _____ _____ _____ _____ _____ _____

The value of 46 is always captured, but this is explained by the time taken to stop, reset and re-start the FTM timer, so we lose a little time.

I edited in the asterixis to show the values used to bin the values into: too short; short(4us); medium(6us); long(8us).

I am not bothered by the runt pulse whose value likely comes from the first captured value. The repeatability is amazing! When I do further captures, the result is nearly always exactly the same (including the single captured value of 47 and the runt pulse).

Code:
Total number of event captured 700
00000 _____ _____ _____ _____ _____ _____ 00001 _____
00008 _____ _____ _____ _____ _____ _____ _____ _____
00016 _____ _____ _____ _____ _____ _____ _____ _____
00024 _____ _____ _____ _____ _____ _____ _____ _____
00032 _____ _____ _____ _____ _____ _____ _____ _____
00040 _____ _____ _____ _____ _____ 00001 00697 _____
00048 00001 _____ _____ _____ _____ _____ _____ _____
00056 _____ _____ _____ _____ _____ _____ _____ _____
00064 _____ _____ _____ _____ _____ _____ _____ _____
00072 _____ _____ _____ _____ _____ _____ _____ _____
00080 _____ _____ _____ _____ _____ _____ _____ _____
00088 _____ _____ _____ _____ _____ _____ _____ _____
00096 _____ _____ _____ _____ _____ _____ _____ _____
00104 _____ _____ _____ _____ _____ _____ _____ _____
00112 _____ _____ _____ _____ _____ _____ _____ _____
00120 _____ _____ _____ _____ _____ _____ _____ _____

It took quite a few runs to capture a slight deviation.

It confirms my observation looking at the histogram captured from genuine double density floppy disk data, the timer results captured by the Teensy3.0 are very repeatable. As a consequence when the 3 pulse lengths of 4us, 6us, and 8us are "binned" the repeatability results in a clean data stream decode. NOTE: the MFM encoding/decoding scheme is very sensitive to even a single pulse mis-bin.
 
I replaced the Teensy3.0 with a Teensy3.1 and re-ran the experiment.

Code:
Total number of event captured 700
00000 _____ _____ _____ _____ _____ _____ _____ _____
00008 _____ _____ 00001 _____ _____ _____ _____ _____
00016 _____ _____ _____ _____ _____ _____ _____ _____
00024 _____ _____ _____ _____ _____ _____ _____ _____
00032 _____ _____ _____ _____ _____ _____ _____ _____
00040 _____ _____ _____ _____ _____ _____ 00698 _____
00048 _____ _____ _____ _____ _____ _____ _____ _____
00056 _____ _____ _____ _____ _____ _____ _____ _____
00064 _____ _____ _____ _____ _____ _____ _____ _____
00072 _____ _____ _____ _____ _____ _____ _____ _____
00080 _____ _____ _____ _____ _____ _____ _____ _____
00088 00001 _____ _____ _____ _____ _____ _____ _____
00096 _____ _____ _____ _____ _____ _____ _____ _____
00104 _____ _____ _____ _____ _____ _____ _____ _____
00112 _____ _____ _____ _____ _____ _____ _____ _____
00120 _____ _____ _____ _____ _____ _____ _____ _____
number of long events captured 0
reading track to test pulse delta timings...
Total number of event captured 700
00000 _____ _____ _____ _____ _____ _____ _____ _____
00008 _____ _____ _____ 00001 _____ _____ _____ _____
00016 _____ _____ _____ _____ _____ _____ _____ _____
00024 _____ _____ _____ _____ _____ _____ _____ _____
00032 _____ _____ _____ _____ 00001 _____ _____ _____
00040 _____ _____ 00001 _____ _____ _____ 00694 _____
00048 _____ _____ _____ 00001 _____ _____ _____ _____
00056 00001 _____ _____ _____ _____ _____ _____ _____
00064 _____ _____ _____ _____ _____ _____ _____ _____
00072 _____ _____ _____ _____ _____ _____ _____ _____
00080 _____ _____ _____ _____ _____ _____ _____ _____
00088 _____ _____ _____ _____ _____ _____ _____ _____
00096 _____ _____ _____ _____ _____ _____ _____ _____
00104 _____ _____ _____ _____ _____ _____ _____ _____
00112 _____ _____ _____ _____ _____ _____ _____ _____
00120 _____ _____ _____ _____ _____ _____ _____ _____
number of long events captured 1
reading track to test pulse delta timings...
Total number of event captured 700
00000 _____ _____ _____ _____ _____ _____ _____ _____
00008 _____ _____ _____ 00001 _____ _____ _____ _____
00016 _____ _____ _____ _____ 00001 _____ _____ _____
00024 _____ _____ _____ _____ _____ _____ _____ _____
00032 _____ _____ _____ 00001 _____ _____ _____ _____
00040 _____ _____ _____ 00001 00001 _____ 00692 _____
00048 00001 00001 _____ _____ _____ _____ _____ _____
00056 _____ 00001 _____ _____ _____ _____ _____ _____
00064 _____ _____ _____ _____ _____ _____ _____ _____
00072 _____ _____ _____ _____ _____ _____ _____ _____
00080 _____ _____ _____ _____ _____ _____ _____ _____
00088 _____ _____ _____ _____ _____ _____ _____ _____
00096 _____ _____ _____ _____ _____ _____ _____ _____
00104 _____ _____ _____ _____ _____ _____ _____ _____
00112 _____ _____ _____ _____ _____ _____ _____ _____
00120 _____ _____ _____ _____ _____ _____ _____ _____

Immediately you can see a substantial variation in a number of captured values. Not always since the first run was clean, apart from the outlier at 88.

It is exactly the same code, I only changed the Teensy type in the "Tools->Board" menu (and re-compiled).

Again I will mention that I am overclocking the CPU at 96MHz, so this can't be ruled out as a reason....until I tried compiling the Teensy3.1 at stock 72MHz (*) and the variation of the captured values remained the same.

(*) the data stream decode won't work at this CPU speed, but the debug code runs fine since the interrupt code to capture values is tiny and trivial (plenty of time at 72MHz).
 
I just noticed that for the Teensy3.1, for every "slightly too long" captured value, there is a matching "too short value".

Looking at the middle table.
Expected value = 46.
Pair values 51 and 43. (43+51)/2 => 47.
Pair values 56 and 36. (56+36)/2 => 46.

It seems to confirm that something is delaying the triggering of the interrupt routine, so it captures a larger than expected timer value, then on the next interrupt it captures a corresponding smaller timer value.
 
Last edited:
Back
Top