www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Taktprobleme AT91SAM7X


Autor: Christophe Thil (chrisjt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus Leutle,

der AT91SAM7X256 auf einem gefertigten PCB macht mir Sorgen. Wie beim 
Eval-Board auch ist die Karte mit 18.432 MHz-Quarz, 10pF Lasten und das 
Schleifenfilter mit 1.5kOhm,  10nF und 1nF bestückt.
Wenn man nun eine auf dem Eval-Board fehlerfrei ablaufende Software 
einspielt stellt man fest, dass die Karte mit der doppelten Freuquenz 
läuft. Insbesondere der USB-Controller funktioniert nicht, aber auch 
RS232 liefert nur Datenmüll.
Stellt man nun den Divider im C-Startup auf den doppelten Faktor, so 
läuft alles (scheinbar) fehlerfrei.

Woran könnte das liegen?

Das Eingangsquarz schwingt mit richtiger Frequenz (aber niedriger 
Amplitude, bei Weitem nicht 1/2 U_In), die Leiterbahnen zwischen CPU und 
Gedöns sind <1cm lang.

Ideen zum Weitersuchen wären super!

Grüße,
Christophe

Autor: Neubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das usb und rs232 nicht funktionieren sollte bei doppeltem system-clock 
logisch sein .... warum das so ist :( ....

kann es sein, dass in deiner quarz-schaltung irgendein unschöner zacken 
am osc-signal entsteht (oberwellen von irgendwelchen signalen -> 
schaltregler, takt/datenleitungen die unter den quarzleitungen 
durchgehen, ...)

-> unter voraussetzung dass deine software alle register richtig setzt : 
aus irgendeinem grund erzeugt der interne schmitttrigger/komparator aus 
deinem sinus-signal 2 takte

-> wenn du den system-clock auf einen portpin direkt ausgeben kannst 
(timer, ..) sollte dabei ein symetrisches (50:50) signal entstehen -> 
wenn nicht : hast du wahrscheinlich oben beschriebenes phänomen 
(unsaubere osc-signale)

-> spektrum deiner osc-signale messen : sollte möglichst nur eine nadel 
sein

Neubi

Autor: Christophe Thil (chrisjt)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hab' eben fix das Oszi dran gehängt.

Das Quarz schwingt ganz ordentlich mit seiner Frequenz. Die Pegel sind 
für mich ATmega-geschädigten aber etwas merkwürdig. Gehört sich das so?!

Der zweite Screenshot stammt von einem GPIO-Pin, den ich (in C) 
programmiert habe, woraus der Compiler folgendes gemacht hat:
    AT91C_BASE_PIOA->PIO_CODR = AT91C_PIO_PA7;
0x001019c8 <main+128>: mvn   r2, #2816  ; 0xb00
0x001019cc <main+132>: mov   r3, #128  ; 0x80
0x001019d0 <main+136>: str   r3, [r2, #-203]
    
    AT91C_BASE_PIOA->PIO_SODR = AT91C_PIO_PA7;
0x001019d4 <main+140>: str   r3, [r2, #-207]
0x001019d8 <main+144>: b     0x1019c8 <main+128>

Wenn ich richtig rechne dauert eine Instruktion somit ungefähr 40ns, 
entsprechend 25MHz. Ist das nicht ein bisschen wenig?

Grüße,
Christophe

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die GPIOs hängen an einem I/O-Bus, dessen Geschwindigkeit mit der CPU 
nicht ganz mitkommt. I/O-Zugriffe erzeugen also Wartezeiten.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Regeln für solche Messverfahren per CPU:

- Code im RAM ausführen, da man im ROM mit Wartezyklen rechnen muss, 
zumal es dem SAM7 im ROM an ausreichend Durchsatz gebricht, nativen 
ARM-Code ungebremst ausführen zu können. Die Atmels sind wie viele 
ARM7-Controller für Thumb-Code konzipiert (löbliche Ausnahme: 
NXP/LPC2000).

- Zwischen die Portzugriffe Warteschleifen einbauen, die weitaus länger 
dauern als die I/O-Zugriffe. Damit werden die Unwägbarkeiten der 
I/O-Zugriffe marginalisiert. Die Laufzeit der Warteschleife lässt sich, 
wenn im RAM, anhand der Angaben zum ARM7TDMI Core ausrechnen.

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo christophe,
es gibt ein paar port pins auf die du mck schalten kannst. versuch das 
mal und messe die ausgegebene frequenz.

gruss
gerhard

Autor: Christophe Thil (chrisjt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Gerhard,

könntest Du mir bitte einen Tip geben welche das sind (bzw. wo ich im 
Manual suchen könnte)? Bin neu bei den Arm-Geschichten...

Danke!
Christophe

Autor: Neubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
osc-signal : min 226mV, max 438mV -> diff : 212mV ....mmmhmmm...

-> hast du das signal auf der OSC-IN leitung gemessen (dann stimmt der 
wert nicht wirklich !)

--->>> unbedingt am ausgang des oscillators messen !!!



kenne jetzt die spec von deinem µc nicht aber kommt mir doch etwas wenig 
vor ?
-> sinus-signalform schaut auf jeden fall ganz gut aus
-> sind die gemessenen pegel nicht etwas wenig (vielleicht erklärt das 
auch die komische clockfrequenz !??)


Neubi

Autor: Neubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-> clock-out sollte auf jeden fall auf einen MCK-OUT-PIN geschalten 
werden ... ansonsten ist das ergebnis nicht wirklich aussagekräftig

.... ausgabe per software und dazu noch in C eher fragwürdig !!

Autor: Christophe Thil (chrisjt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Unterschied an den beiden Quarz-Beinchen ist nicht sonderlich groß. 
Wenn man dem Tek-DPO traut 10mV. Mir kommen diese Pegel auch etwas 
komisch vor. Könnte das jemand mit seinem ARM-Board vergleichen?! Wäre 
äußerst hilfreich!

Ich bin gerade dabei das Manual zu durchwühlen wie man den MCK auf einen 
Output-Pin bekommt. Tips dazu wären natürlich super ;)

Christophe

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PMC 25.6

Autor: Christophe Thil (chrisjt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, wenn ich das richtig verstanden habe sollten die zwei Zeilen
  AT91F_PIO_CfgPeriph(AT91C_BASE_PIOB, 0, AT91C_PMC_PCK1);
  AT91F_PMC_EnablePCK(AT91C_BASE_PMC, 1, AT91C_PMC_CSS_PLL_CLK);
ausreichen um an PB21 den PLL-Takt auszugeben?

Christophe

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo christophe,
dein beispielcode sieht mal gut aus.

btw:
das messen am oszillator-pin bringt sicher nur falsche ergebnisse da du 
mit der kapazität des oszi-probe den quarz verziehst (und das noch dazu 
einseitig).
die 10pf lastkapazität kanst du dir sparen wenn dein quarz nicht mehr 
als 20pf benötigt da die interne kapazität des at91sam7x schon 20pf 
beträgt.
die 10pf sind zwar in den schematics von den atmel-ek boards immer drin 
aber eigentlich immer unnötig.

gruss
gerhard

Autor: Christophe Thil (chrisjt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

am SAM ist das übliche Reichelt-Standardquarz angeschlossen, was wohl 
32pF Last benötigt.

Ich werd' mich jetzt mal wieder ans Oszi setzen und den Taktausgang 
messen, vielleicht auch mal die Lastquarze auslöten.

Grüße,
Christophe

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo christophe,
wenn de rquarz wirklich 32pf lastkapaz. braucht dann sind die 10pf 
gerade richtig!
außerdem kann trotz falscher lastkapazität die frequenz nicht um den 
faktor 2 falsch sein.
ich würde mal den beispielcode nochmals in eval board laden und sehen ob 
der wirklich läuft.
falls du einen debugger hast kannst du ja mal die register des pmc 
auslesen und sehen wie die divider/multiplier der pll wirklich stehen.

gruss
gerhard

Autor: Christophe Thil (chrisjt)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, nächster Versuch.

Es hat geklappt den Main/PLL-Takt auf einem externen Pin auszugeben. Der 
Code von oben stimmt nicht ganz, zur Referenz hier der korrekte:
  AT91F_PMC_EnablePCK(AT91C_BASE_PMC, 2, AT91C_PMC_CSS_MAIN_CLK);
  AT91F_PIO_CfgPeriph(AT91C_BASE_PIOB, 0, AT91C_PB22_PCK2);

Man kann wunderbar die 18,432 MHz Main-Clk des Quarzes sehen.

Was mich jedoch etwas wundert ist der PLL-Takt. Bei den bekannten 
Einstellungen hätte ich ~ 100MHz erwartet, sehen kann man jedoch das 
doppelte.

Mit dem JTAG-Debugger habe ich vorhin die Bits des Konfigregisters 
ausgelesen, die mit dem C-Code übereinstimmen (übrigens direkt aus dem 
"Getting Started"-Code kopiert):
    AT91C_BASE_PMC->PMC_PLLR = AT91C_CKGR_USBDIV_1           |
                               AT91C_CKGR_OUT_0              |
                               (16 << 8)                     |
                               (AT91C_CKGR_MUL & (72 << 16)) |
                               (AT91C_CKGR_DIV & 14);

Und nun? Mir fällt so langsam nichts mehr ein...

Christophe

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo christophe,
das einzige was mir bei o.a. startup-code noch auffällt ist, das du 
PLLCOUNT nicht init.
versuch mal AT91C_CKGR_PLLCOUNT einzusetzen.

gruss
gerhard

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
allo christophe,
fehler meinerseits, hatte
(16 << 8)
übersehen.
trotzdem mal mit AT91C_CKGR_PLLCOUNT probieren.

gruss
gerhard

Autor: Christophe Thil (chrisjt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich habe nochmal alles überprüft.
Startup-Code ist
    AT91C_BASE_PMC->PMC_PLLR = AT91C_CKGR_USBDIV_1               |
                               (AT91C_CKGR_MUL & (72 << 16))     |
                               AT91C_CKGR_OUT_0                  |                               
                               AT91C_CKGR_PLLCOUNT               |                               
                               (AT91C_CKGR_DIV & 14);
[...]
    AT91C_BASE_PMC->PMC_MCKR = AT91C_PMC_PRES_CLK_2;
[...]
    AT91C_BASE_PMC->PMC_MCKR |= AT91C_PMC_CSS_PLL_CLK;
und in den Registern stehen auch diese Werte jeweils drin:
AT91C_CKGR_MCFR = 0x0001267f
AT91C_CKGR_PLLR = 0x10483f0e (Div=14, Mul=72)
AT91C_PMC_MCKR = 0x00000007 (PLL-Takt benutzen und durch 2 teilen)
AT91C_PMC_SR = 0x0000040d

Ein flash info 0 zeigt mir übrigens auch die ungefähren 48 MHz an:
master clock(estimated): 51386kHz
Allerdings weiß ich nicht wie diese ermittelt werden.

Habe auch mal versuchsweise den _OUT-Parameter von 0 auf 1, 2 und 3 
geändert, was aber zur Folge hatte dass gar nichts mehr lief.

Bin ehrlich gesagt ziemlich ratlos :(


Christophe

Autor: Christophe Thil (chrisjt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe heute gesehen, dass auf dem Eval-Board ein AT91SAM7X*C*256 
drauf ist. Hat jemand ein Board mit der nur-C-Variante im Einsatz? 
Mittlerweile gehe ich schon fast davon aus, dass der Controller 
fehlerhaft ist. Als temporärer Workaround kann man den USB- und 
Main-Takkteiler von 2 auf 4 erhöhen.

Christophe

Autor: Bernd Schuster (mms)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AT91F_PIO_CfgPeriph(AT91C_BASE_PIOB, 0, AT91C_PMC_PCK1);

welche Bedeutung hat in diesem Zusammenhang die 0?

Bernd

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>AT91F_PIO_CfgPeriph(AT91C_BASE_PIOB, 0, AT91C_PMC_PCK1);
>welche Bedeutung hat in diesem Zusammenhang die 0?
der entsprechende pio pin soll auf peripheral b geschaltet werden.
siehe datenblatt kapitel "Peripheral A or B Selection"

gruss
gerhard

Autor: Christophe Thil (chrisjt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
…um hier noch (nach langer Zeit) der Sache ein Ende zu geben: Wir hatten 
einen Fehler auf der Platine, und zwar waren VDDPLL und PLLRC 
vertauscht. Warum dann trotzdem die PLL anläuft und einen Takt mit 
Faktor 2 liefert wird wohl ewig ein Rätsel von Atmel bleiben ;)

Trotzdem euch allen nochmal vielen Dank für die Bemühungen!
Christophe

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.