32768kHz klocka ligger lite fel men sen kompenseras?

[Dalmas]

Hej,
Utför en hel del prover på hur exakt en 32768Hz kristall är i en uP-lösning. Jag använder mig av en 10ppm 32768Hz klocka som referens.
Alltså, mätobjektet (en uP med en kristallen som ska undersökas) lägger ut en puls varje sekund på en utgång. Denna utgång detekteras av Labview.
Samtidigt är referensklockan ansluten till Labviews hårdvara som har en counter. Ingången, som känner av sekundpulsen, grindar countern så LV kan läsa av den "on-the-fly".
Nu visar det sig (och även tidigare tester) att tiden mellan pulserna kan vara lite över en sekund, typ 1.01 sek ett antal gånger i följd men sen kommer en tidig puls som raderar ut felet som ackumulerats tidigare. Det slutar alltså med att på längre sikt är uP:ns kristall väldigt noggrann även om momentana värden har ett litet fel.
Känner nån igen detta fenomen eller är jag blind?

Det kan ju inte vara nåt "automatiskt"? Snarare att nåt driver och sen "driver över" över hamnar rätt igen. Jag önskar höra era åsikter.

Labviews noggrannhet har testats med referensklockan utan nåt "mätbojekt" mellan. Den tycks detektera pulsen korrekt och har en hög repeternoggrannhet. Jag har inte loggat detta, bara observerat fenomenet vid två vitt skilda tillfällen och med olika riggningar/utrustning. Känner mig lite dum. Är det nåt jag förbisett?

[Icecap]

32kHz kristaller är inte enkla att få rätt. Dels får de inte få för mycket energi när de svänger (kan spricka annars) och dels måste den kapacitiva belastningen vara helt korrekt för att den ska vara inom specifikationerna.

Vilken kapacitiv belastning har du monterat?
Är det någon trim-möjlighet?

[rvl]

Är det ett program i uP:n som lägger ut sekundpulsen? Har uP:n övriga uppgifter med högre prioritet som får pulsen att dröja ibland? Men genereras pulsen med ren HW, så får vi hittanån annan förklaring.

[Dalmas]

Det är kristallens IRQ-rutin. Pulserna går via en HW-prescaler som skapar ett avbrott varje sekund. I detta avbrott skapar jag pulsen.
Ja, det är lurigt. I slutändan funkar alltså det hela (ingen märker nåt) men jag blir inte klok på beteendet.

[Klas-Kenny]

Skulle det möjligen kunna vara något med samplingshastighet där någon multipel kommer väldigt nära en sekund, men inte exakt i synk med din klocka?
Så ibland landar pulsen i en tidigare, och ibland i en senare sampling. Så snittet blir rätt, men det kan fela något fram och tillbaka i de mätta tiderna.

[Jan Almqvist]

Kan det vara så att interrupt är disablat ibland t.ex. av annat interrupt med högre prioritet?

[Dalmas]

Ja, jag har funderat på att fenomenet kommer från "nån" sampling. Nåt som driver lite men eftersom jag stött på fenomenet på två vitt skilda testanläggningar så måste(?) detta ske ganska nära kristallen, i uP som jag testar (Atmels processorer). Det är som om ingångssteget för kristallen besitter detta beteende.

[Dalmas]

Ja. Avbrottet kan nog vara disablat pga ett annat avbrott. Som jag minns kunde man inte ha prio på avbrotten i Atmels. Finns inget sånt register...
Det finns alltså två källor i denna lösning där uP sitter. Ett XTAL och en annan krets som inte har sån superbra timing. Det skulle kunna vara det som skapar detta....ska fundera en vända till. Nästa gång jag ser detta ska jag stänga av avbrottet från den andra kretsen o se om det skiljer sig.

[prototypen]

Nu är det så att 32768 är jämnt delbart med 2 så varför inte använda en 4060 + ett steg till så kommer du undan alla möjligheter att uP strular till det.
Sedan är ju kristall drivern i en uP ingen höjdare. Kanske behövs en dedikerad driver.

Protte

[sodjan]

För att utesluta att det inte är din mätuppkoppling som genererar
fenomenet, så kanske du kan testa med något annat?
En vanlig puls/frekvensmeter kanske?

Fenomenet som du beskriver, hur stabilt är det? Är det alltid
samma antal 1.01 sek pulser innan det "justeras"? Det låter
som något interferens fenomen mellan signalkällan och det
som du mäter med...

[Dalmas]

Jag har testat ut mätsystemet för att se att det inte påverkar mätresultatet och jag kan konstatera att det är stabilt. Skapar ingen drift åt nåt håll. Då har jag använt mig av referensklockan (10ppm) rakt in i mätsystemet utan detta "mätobjekt" mellan. Jag satt en 4040 x 2 och dragit ut bit 22 (?) så pulserna som kom ut var 64s långa. Dessa pulser lästes av med en mkt hög noggrannhet och dessutom stabilt över tid.

Det som inte finns är noteringar. Jag har inga minnesanteckningar från de gånger jag stött på detta beteende så därför är det svårt för mig att exakt säga hur kopplingen var men det jag vet är att det satt en uP mellan som jag ville kolla noggrannheten på och samtliga uP-baserade system hade ett klockavbrott.

Så jag kan kallt konstatera att det är mätobjektet med 32k kristall o uP med IRQ-rutin som skapar denna "offset" under ett antal gånger i följd med en efterföljande "kompensering" som suddar ut det accumulerade felet. Jag börjar misstänka att att det är en interferens mellan två avbrott i mätobjektet. Dessa två driver gentemot varandra. Det *vet* jag. Den ena går med 1s och den andra med 4 ggr per sek men mer osäkert.
Det mer osäkra avbrottet som går med 4Hz borde tas bort och flyttas över till 1s avbrottet men det går inte hur enkelt som helst för 4Hz klockan är motorn i en statemaskin. Så då blir det att köra capture på en räknare...dvs, dela ner 1s avbrottet till 4ggr/sek. Då kan jag koppla bort all kod i det andra avbrottet...

För att knyta ihop säcken. Jag ska, nästa gång jag stöter på detta, stänga av avbrottet från 4Hz källan och se om det är den som påverkar.

[rvl]

Då verkar det vara rätt uppenbart at ~4 Hz avbrottet är "boven", men spelar det nån roll för applikationen?

En tanke kunde vara att faslåsa 4 Hz till 1 Hz källan på ett eller annat sätt. T.ex. låta den gå litet för fort och vid vart fjärde state vänta in rätt tid att fortsätta, samt vid dessa tillfällen även sköta det som det separata 1 Hz interruptet sköter nu.

[Dalmas]

Ja. 4Hz avbrottet är troligtvis boven. Kan inte se nån annan anledning. Det gör inget för funktionen verkar det som. Tidigare var 4Hz pulsen tidshållaren i konstruktionen men sen ökade kraven på "tiden". Så då anslöts en klockkristall men tyvärr användes inte den som huvudklocka för hela systemet utan endast de funktioner som krävde noggrann tid. Ex.vis statemaskinsmotorn som gör allt jobb går fortfarande med 250ms. Det restes varnande fingrar för denna uppdelning med två klockor och jag tror detta jag ser är konsekvensen av att det finns två "hjärtan". Har aldrig gillat läget faktiskt men som det nu fungerar tror jag inte det är lönt att lägga nån tid på att koda om.