Hallo zusammen, ich habe mal wieder ein Problem mit dem AT91SAM9XE ich habe mir selbst ein Board gebaut. Ich kann über einen Jumper zwischen Externen Oscilator und internem wählen. Wenn ich den Internen wähle, kann ich nicht Programmieren. Wenn ich den Externen Wähle kann ich zwar Programmieren aber der Kontroller startet nicht. Kann mir jemand sagen woran das liegen kann? hat jemand Erfahrung damit gemacht?
Hallo Max, ich habe auch noch ein Design mit einem AT91SAM9X512 im CAD stecken und habe statt dessen mein AT91SAM9G10 in die Praxis umgesetzt. Mir ist da diesbezüglich eines internen Oszillators gar nichts bekannt ?!? Oder bezieht sich das nur auf die RTC ? (Slow Clock 32KHz) Geht denn der JTAG-Port ? Wird die PLL benutzt ? Ich Denke einen externen Quartz so mit 3-20MHz wirst du schon brauchen. Denn der Bootloader benötigt es schon. PS. wollte mal das Kamerainterface ausprobieren. Der AT91SAM9X ist ein super ARM9 Derivat mit Flash. Gruß Sascha
Sascha schrieb: > Hallo Max, > ich habe auch noch ein Design mit einem AT91SAM9X512 im CAD stecken und > habe statt dessen mein AT91SAM9G10 in die Praxis umgesetzt. > Mir ist da diesbezüglich eines internen Oszillators gar nichts bekannt > ?!? > Oder bezieht sich das nur auf die RTC ? (Slow Clock 32KHz) > Geht denn der JTAG-Port ? > Wird die PLL benutzt ? > > Ich Denke einen externen Quartz so mit 3-20MHz wirst du schon brauchen. > Denn der Bootloader benötigt es schon. > PS. wollte mal das Kamerainterface ausprobieren. > Der AT91SAM9X ist ein super ARM9 Derivat mit Flash. > > Gruß Sascha Es bezieht sich auf die Slow Clock. Den Hauptquarz habe ich ca. 18 MHz. Ich programmiere im SWD Modus. Wie gesagt im einen kann ich programmieren. Im anderen läuft der MC. Hat die das Signal an OSCSEL noch weitere nicht im Datenblatt erwähnte Einflüsse? PLL benutze ich nicht.
Ich Programmiere dem SAM-ICE von Segger + J-Link. Was meinst du mit was? Was für ein Programm? Das variert. Vom einfachen Programm bei dem ich ein paar Pins setze bis hin zu Demo Projekten von Atmel.
Hallo, mus kurz nachfragen SWD-Mode ? Ich kenne nur JTAG bei den ARM9 Controllern. SWD wird doch erst bei Cortex M3 unterstützt oder ? Gruß Sascha
hallo max, meine frage war unklar formuliert. mit "was" meinte ich welches flash, das interne oder ein externes? mit welcher pc-software arbeitest du? ich nehma mal an dass du mit dem pin OSCSEL die umschaltung zwischen internem RC oscilator und einem ext. 32khz quarz vornimmst. ist dies korrekt? gruss gerhard
Ich programmiere das intere Flash. Ich habe auch keine externen Speicher angeschloßen. Ich Flashe qwie gesagt mit segger J-Link. Ich Kompiliere mit GNU-elf. bzgl OSCSEL ist deine Feststellung Richtig.
hallo max, ich vermute mal dass der j-link mit dem ungenauen internen rc-oszillator nicht zurecht kommt bzw. die initialisierung des clock-systems damit nicht funktioniert. ich würden mal den ext. 32khz quarz einsetzen. damit funktioniert das programmieren ja offensichtlich. deine software muss dann natürlich das oszillator-system entsprechend initialisieren (passiert normaleweise in einer lowlevelinit funktion. schon mal mit einem debugger die ursache gesucht? gruss gerhard
Zu erst ich habe noch nicht mit dem Debugger gearbeitet. Nein ich kann mit dem externen eben nicht programmieren nur mit dem internen bei dem Läuft der Controller aber nicht. In der Lowlevelinit wird die Main Clock ausgewählt. Wie ich zwischen interner und externer Slow Clock wechseln kann ist für mich, außer über den OSCSEL-Pin, nicht ersichtlich. Habe ich da im Datenblatt was übersehen?
Der J-Link geht doch über JTAG auf die CPU und dann müsste doch der SlowClock von der Genauigkeit egal sein, dürfte nur Intressant sein wenn man über die die UART mit Samba geht. Dürfte dann eher am Bootloader und deren Pins noch ein Problem sein ? Gruß Sascha
hallo max, ich würde dir empfehlen einen quarz an den main oscillator anzuschalten, da du sonst die pll nicht nutzen kannst und ohne der pll wirst du keine vernünftigen PCK und MCK erhalten (außer du möchtest ernsthaft den prozessor mit 32khz takten). gruss gerhard
Hallo Gerhard, wer lesen kann ist im Vorteil, hat er doch oben geschrieben.
>wer lesen kann ist im Vorteil, hat er doch oben geschrieben.
wo hast du gelesen, dass er den prozessor mit 32khz takten möchte?
Hallo zusammen, also ich möchte den nicht mit 32kHz takten. Aber ich habe schon einen Quarz am Main Oscilator. Da habe ich wie gesagt einen 18,432MHz Quarz.
>Da habe ich wie gesagt einen 18,432MHz Quarz.
das hast du hier aber zum ersten mal "gesagt".
hast du dir schon mal die modul board_lowlevel.cvon aus den atmel
examples angesehen?
gruss
gerhard
Ich habe weiter oben schonmal geschrieben das ich als Hauptquarz einen ca. 18 MHz Quarz verwende. Ist ja nicht das Problem ich bin ja dankbar für die hilfe da sage ich das auch gerne zweimal :). Ja die habe ich mir bereits angesehen. darauf bezog sich meine vorletzte Antwort. Das da ja auf Main Oscilator umgeschaltet wird.
Hallo Max, mit dem JLINK köntest du auch aus dem Flash debuggen, um zu sehen wie weit der Prozessor kommt, fals er irgendwo hängen bleibt. Das geht auch ganz ohne IDE du brauchst dich nur in das Segger Tool JLINK.EXE etwas einarbeiten. Auch die Speicherbereiche kann man damit testen. Die Jumperung vom internen Boot-Loader ist die O.K. ? Hast du schon mal mit dem SAMBA Tool von Atmel probiert zu flashen ? Das unterstützt den JLINK übrigens auch. Aber vorsicht da gibt es zwei Versionen. Ich finde die JTAG Debugger sache einfach super, weil man sehr schnell Fehler finden kann.Besser als ständig "Tray and Error". Gruß Sascha
Ich hatte schon mehrfach mit dem Debugger getest wie der Controller läuft. Nicht allerdings wenn er scheinbar nicht gelaufen ist. Bei OSCSEL=1 werden die Port-Pins nicht gesetzt. Deswegen dachte ich er läuft nicht. Jetzt habe ich mit dem Debugger getestet der PC ändert sich. Aber wenn ich den Controller einfach laufen lasse steht der PC hinterher auf PC=0x00000010. Da ich im Flash ab Addr.: 0x00200000 das Programm habe kann das ja nicht stimmen. Sobald er bei dieser Adresse (0x10) steht passiert aber auch nichts mehr. Darüberhinaus wenn ich resete und anhalte beginnt der PC auch bei einer Addresse 0x00000XXX. Das leuchtet mir insofern ein als das da das Boot-Programm drin steht. Wie gesagt wenn ich laufen lasse endet es bei Adresse: 0x10. Dann habe ich angehalten und einzelschritt gemacht. bis auf einmal folgende Fehlermeldung kam: Error: Failed to read current instruction. Also habe ich das PC gelesen und siehe da auf einmal bin ich an Adresse: 0x01 6A B9 84. Also im reservierten Speicherbereich. Im Gleichen Modus OSCSEL =1 nochmal gestartet nach Reset. Kommt eine Warnung das der PC-Wert unerwartet ist.PC auf 0x0000 0000 gesetzt und einzelschritt. ging erstmal ohne Probleme. Irgendwann kam BAD JTAG Communictaion. danach muss ich erst die Spannung wegnehmen, damit ich wieder auf den MC komme. der hat dann eine Addresse PC= 0x00200844. Also irgendwie bringt mich das auch nicht weiter. Habt ihr da erfahrungen, das ihr sagen könnt, daran kann das liegen?
hallo max, aus meiner sicht hast du ein hw-problem. ich habe mal beim original atmel sam9xe-ek mittels j-flash und j-link das interne flash programmiert. egal mit welcher OSCSEL-Einstellung ich das board starte funktioniert das programmieren ohne probleme. gruss gerhard
Hallo Max, Adresse 0x10 ist schon mal ein Zeichen das man gut interpretieren kann, es ist exection vector "Data Abort" d.h. der Prozessor greift auf einenen Speicherbereich, den es gar nicht gibt. Der Prozessor fängt immer bei Adresse 0x00 an und das Flash sollte nun in diesem Bereich gespiegelt werden. Natürlich liegt es immer physikalisch auf Adresse 0x200000 es gibt da ein Remapping zwischen dem Boot-Loader und dem Flash, sowie mit dem internen SRAM. Seite 20,22,23,24,25 im Manual lesen. So ganz genau stecke ich da jetzt auch noch nicht drin, es intressiert mich aber auch, weil ich den Chip auch einsetzen will. Dann haben die ersten Derivate des 9XE auch noch eine gute Errata Liste besonders die Typen mit der Bezeichnung AT91SAM9XExxx-QU-ES 07511 A es waren die ersten Samples die ausgeliefert wurden. Ha von denen habe ich hier 4 Stück rumliegen. Mittlerweile werde ich auch nochmal neue bestellen. Zumindest auch nochmal genau das Errata sheet lesen. Gruß Sascha
Hey Sascha, hallo Gerhard, als ich heute morgen von der Arbeit kam und den Beitrag von Sasha gelesen habe. Dachte ich mir noch was sollst du damit anfangen. Weil warum soll das Programm in an eine nicht existente Adresse springen. Bei anderen Funktioniert es ja und ich habe keine Sprünge eingefügt. Und selbst wenn würde der Kompiler da ja nicht so vermurksen. Als ich aufgewacht bin kam es mir. Jetzt habe ich einen Verdacht, dem ich später mal nach gehen werde. Ich habe das SD-Karten-Beispiel Programm. Immer wenn dort etwas nicht nach Plan läuft. Kommt eine Fehlermeldung auf DBG (die ich aber nicht benutze). Anschlißend wird ein Return ausgeführt. Da ich nicht wusste wie sich das verhält, habe ich ne while(1); davor eingefügt. Meine Vermutung: while(1); wir wegoptimiert. Anschließend wird return ; ausgeführt. Und zack ist er irgendwo im nirgendwo. Wie gesagt, ich werde das später testen und dann nochmal Feedback geben. Mit freundlichen Grüßen Max
Hallo Max, was mir in einem solchen Fall schon mal passiert ist, sind Sprünge mit einer Absoluten Adresse. Nach einem Remap geht es halt nur mit relativer Adressierung. Oder der Code wird für diesen Adressraum extra geschrieben. Innerhalb des Codes darf also nur relativ gesprungen werden und auf andere Bereiche darf dann nur absolut gesprungen werden. Ich meine bei einem Compiler kann man dem Linker das angeben. in Assembler ist das etwas einfacher oder sagen wir mal direkter. B Ziel_Routine //ist in dem Fall relativ und ldr r0=Ziel_Routine BX r0 //ist in dem Fall direkt also Absolut Wenn aber das Flash + die Spiegelung immer sichtbar ist, ist das egal. Wichtig ist in dem Fall das die Interrupt alle gut angelegt sind und abgefangen werden. Ich habe mir jetzt auch mal die Mühe gemacht und die Low Level Routinen von Atmel mir angesehen, na ja also da muss ich schon sagen es dürfte etwas mehr an initialisierung sein. Auf jeden fall bin ich mal gespannt was das Problem ist !
Also ich habe jetzt mal an der Stelle an der es zum Fehler kommt den Code aus dem Speicher gelesen und Analysiert. Der Befehl vorher ist ein Single Data Transfer bei dem von Register 2 in Register 3 "kopiert" wird. Der Befehl bei dem er rausfliegt. ist eine Data Processing / PSR Transfer-Befehl genauer ein MOV-Befehl bei dem er nach meinem Verständnis einen konstanten Wert in Register 3 schreibt. Warum das dazu führt das er Abstürzt verstehe ich nicht. Dann nehme ich den Controller vom Netz. Anschließend wieder ans Netz. er ist jetzt an einer Adresse von wo er wieder läuft und eine Endlosschleife produziert.
Habe da nochmal ne Frage. Wird irgendwo der aus dem C-Code der Asm-Code erzeugt (habe ihn nicht gefunden) bzw. gibt es da die Möglichkeit den zu bekommen? (Also aus meinem C-Code)
Hallo Max, kanst du mir von dem oder der Opcodes eine Kopie machen. Ich kann das ohne Probleme aufschlüsseln, wenn der Debugger es nicht kann. Ich habe früher Reverse-Engineering auf ARM7 gemacht und habe noch alle meine OP-Code Tabellen. Das Problem kann aber schon weiter vorne im Code entstehen, wenn die execption trap interrupts nicht richtig behandelt werden. Leg mal für jeden execption trap (interrupt) eine endlos Schleife an. Und schalte bei der CPU den unalignment fault ein. Oder lade dir von Keil oder IAR eine Demoversion herunter und probier es damit, wenn du schon einen JLink hast. Es müsste von IAR auch eine Kikstart Version geben 32K Limited oder so. Dort hast du wenigstens einen guten Debugger, der alle execptions abfangen kann. Mit welcher Software arbeitest du überhaupt ? Ich habe mal Eclipse Yagarto ausprobiert, das fand ich schrecklich. Bin jetzt auch noch auf der Suche nach einer einfachen IDE. Assembler von GNU/GCC ist für mich O.K. auf DOS ebene. Aber einen Debugger standalone mit JTAG/Jlink Unterstüzung wäre eine feine sache. Gruß Sascha
Hey ich habe nochmal eine Frage. Was hat es zu bedeuten, wenn der MC an die Adresse 0x0000000C springt. Gibt es da eine Tabelle wo man das nachschauen kann?
>Gibt es da eine Tabelle wo man das nachschauen kann?
schon mal vom "ARM Architecture Reference Manual" gehört?
findest du z.B. hier:
www.scss.tcd.ie/~waldroj/3d1/arm_arm.pdf
dort wird dir geholfen!
gruss
gerhard
Hallo Max, Adresse 0x0C ist Abort Prefetch. Das habe ich noch nicht geschaft...... Wie bekommt man das hin ? Aber ich glaube bei dir stimmt irgendetwas überhaupt nicht !!! Nimm doch mal eine ordentliche IDE. Und dann lesen und verstehen was ein ARM9 Core so alles hat,kann und macht. Bei Atmel auf der Homepage gibts doch alles zum Download. oder über Suchmaschiene "DDI 0198E" und "DDI 0081E". Gruß Sascha
Hallo Sascha, das ist eigendlich gar kein Problem. Mache ein return 0; dann kommst du auch an die Adresse 0x0C. Das wird in den Bespielen von Atmel so ausgeführt. Mit Keil konnte man dem Fehler näher kommen. Das ganze ist nicht direkt ein Problem vom Controller. Ich greife auf die Speicherkarte (MicroSD) zu. Die wird aber als nicht formatiert erkannt. => Sie wird formatiert. Danach wird sie immer noch nicht als Formatiert erkannt. Daraufhin verlässt der Controller mit return 0; die Main. Das ist alles von Atmel vorgeben. Nur ohne Debugger war das ganze nicht zu finden. Wobei der Debugger bei dem ich nur Byte-Code aus dem Speicher, bzw. eigentlich nur Adressen anschauen konnte, nicht ausreichend war. Jetzt gilt es herauszufinden wo das Problem liegt. Aber ich bin schonmal froh das Grundsätzlich alles iO ist. Vielen Dank für eure Hilfe und Bemühungen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.