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
Gast
#569504
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
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:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
Wenn ich richtig rechne dauert eine Instruktion somit ungefähr 40ns, entsprechend 25MHz. Ist das nicht ein bisschen wenig? Grüße, Christophe
Angehängte Dateien:
-
oszi.png
(73 KB)
Gast
#569637
Die GPIOs hängen an einem I/O-Bus, dessen Geschwindigkeit mit der CPU nicht ganz mitkommt. I/O-Zugriffe erzeugen also Wartezeiten.
Gast
#569639
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.
Gast
#569756
hallo christophe, es gibt ein paar port pins auf die du mck schalten kannst. versuch das mal und messe die ausgegebene frequenz. gruss gerhard
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
Gast
#569852
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
Gast
#569854
-> 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 !!
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
Gast
#569898
PMC 25.6
Okay, wenn ich das richtig verstanden habe sollten die zwei Zeilen
1 | |
2 | |
ausreichen um an PB21 den PLL-Takt auszugeben? Christophe
Gast
#570017
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
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
Gast
#570026
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
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:
1 | |
2 | |
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):
1 | |
2 | |
3 | |
4 | |
5 | |
Und nun? Mir fällt so langsam nichts mehr ein... Christophe
Angehängte Dateien:
-
pll2.png
(36 KB)
Gast
#570133
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
Gast
#570136
allo christophe, fehler meinerseits, hatte
1 | |
übersehen. trotzdem mal mit AT91C_CKGR_PLLCOUNT probieren. gruss gerhard
So, ich habe nochmal alles überprüft. Startup-Code ist
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
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
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
1 | |
welche Bedeutung hat in diesem Zusammenhang die 0? Bernd
Gast
#682373
>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
…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
Bitte melde dich an, um einen Beitrag zu schreiben.