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
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
AT91C_BASE_PIOA->PIO_CODR = AT91C_PIO_PA7;
2
0x001019c8 <main+128>: mvn r2, #2816 ; 0xb00
3
0x001019cc <main+132>: mov r3, #128 ; 0x80
4
0x001019d0 <main+136>: str r3, [r2, #-203]
5
6
AT91C_BASE_PIOA->PIO_SODR = AT91C_PIO_PA7;
7
0x001019d4 <main+140>: str r3, [r2, #-207]
8
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
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.
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
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
-> 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
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
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:
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
AT91C_BASE_PMC->PMC_PLLR=AT91C_CKGR_USBDIV_1|
2
AT91C_CKGR_OUT_0|
3
(16<<8)|
4
(AT91C_CKGR_MUL&(72<<16))|
5
(AT91C_CKGR_DIV&14);
Und nun? Mir fällt so langsam nichts mehr ein...
Christophe
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
So, ich habe nochmal alles überprüft.
Startup-Code ist
1
AT91C_BASE_PMC->PMC_PLLR=AT91C_CKGR_USBDIV_1|
2
(AT91C_CKGR_MUL&(72<<16))|
3
AT91C_CKGR_OUT_0|
4
AT91C_CKGR_PLLCOUNT|
5
(AT91C_CKGR_DIV&14);
6
[...]
7
AT91C_BASE_PMC->PMC_MCKR=AT91C_PMC_PRES_CLK_2;
8
[...]
9
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
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
>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