Hallo Leute, stehe kurz vor der verzweifelung. Ich habe gestern die Eval Version von Rowley (1.7) installiert und wollte mit dem AT91SAM7S256 Header board wenigstens mal ne LED zum blinken bringen. Es will winfach nicht. Hier mal das Code-Schnipsel : #include <targets/AT91SAM7S256.h> void vDelay (void) { unsigned long ulC; for (ulC = 0; ulC < 600000; ulC ++); } void vInitLED (void) { PMC_PCER = 1 << PIOA_ID; //LED 1 //configure the PIO Lines corresponding to LED1 PIOA_PER = 0x100; //Enable PA17 PIOA_OER = 0x100; //Configure in Output PIOA_SODR = 0x100; //set reg to 1 } void vSetLED (char ucOnOff) { if (ucOnOff) { PIOA_SODR = 0x100; //set reg to 0 (led2 on) } else { PIOA_CODR = 0x100; //set reg to 1 (led1 off) } } int main (void) { vInitLED (); while (1) { vSetLED (0); vDelay (); vSetLED (1); vDelay (); } } Der Startupcode ist der AT91SAM7_Startup.s (von 2004). Blinken tut nichts. Es geht noch nichtmal die LED an. Debuggen (also debugpunkt auf vInitLED) geht auch nicht. Ich muß sogar jedesmal das Board von der Spannung abziehen und wieder neu dranmachen, damit ich überhaupt porgrammieren kann. Sonst kommt (bei Start Debugging) immer die Fehlermeldung "Cannot Stop Device". Mittlerweile lässt sich das Board noch nichteinmal mehr fehlerfrei programmieren (Flash inhalt und .elf datei sind unterschiedlich) Das der ARM ne nummer komplexer ist als AVR und MSP ist klar, aber das gar nichts mehr geht, noch nichteinmal ein dummes blinken ? Ich kapier nicht was ich falsch mache. Beim LPC2106 hatte ich bei weitem nicht solche Probleme. Möchte aber mit dem ARM7 arbeiten wegen dem SSC. Kann mir da irgendjemand helfen das ich wenigstens einen einfachen dämlichen Blinker ans rennen bekomme ? Kann doch nicht sein das ich sooo blöd bin oder ?! Frustrierte Grüße Rene
Mit dem Controller kenn ich mich jetzt zwar nicht so genau aus, aber nunja... Kommst du beim Debuggen überhaupt in die main-Funktion? Wenn nicht, dann probier mal durchs Startup-File zu debuggen. Vielleicht ist da ja noch was nicht in Ordnung. Aber eigentlich hört sich das für mich eher danach an, dass du dein Memory-Layout nicht richtig konfiguriert hast. Also jedenfalls hatte ich aus diesem Grund bei anderen ARM-Controllern probleme. Schau doch bitte mal nach ob die Angaben für Flash und RAM dem vom Target entsprechen. Gruß PeggySue
@peggy also den startup-code kann ich debuggen. und habe auch schon die stelle gefunden an der es kracht : /* Enable user reset */ ldr r1, =RSTC_BASE ldr r0, =0xA5000001 str r0, [r1, #RSTC_MR_OFFSET] danach hängt das dingen im nirvana. jetzt muß ich nur noch rausbekommen warum der nach 0xa500001 will. das memory-mapping habe ich mir versucht anzuschauen (flash_placement.xml), allerdings stehen in dem xml file zwar alle sections, aber keine startadresse zu den jeweiligen sections. mekrwürdig ist nur das das bei den olimex_arm7_p64.hzq genauso steht. (also auch keine start-adressen). ist das überhaupt das memory mapping (also die flash_placement.xml) ?!
ok ... es lag also an 0xa5000001. habs auf 0x00100000 (anfang des flashs) geändert und nun blinkt es. mal ne frage : wo bekommt man die start-up-codes mit entsprechender beschreibung was diese codes machen ?! kann ja eigentlich nicht sein das man erstmal rästelraten muß warum der startup-code jetzt nicht läuft oder ?! ich meine mit rowley hat man eine schöne stabile umgebung, aber man kann ja nicht davon ausgehen das jeder sowas hat. also irgendwie steh ich der arm-programmierung noch etwas skeptisch gegenüber (wobei ich denke das wenn man die anfänglichen probleme überwunden hat die teile einfach nur geil sind, aber muß das soo kompliziert sein ?!)
Der Startup-Code ist von Rowley, da wirst du die Fragen müssen, was der macht. Da kocht so ziemlich jeder sein eigenes Süppchen. Jeder macht noch eigene Sachen rein, z.B. eigene IRQ-Routinen. Das macht es für Anfänger nicht gerade einfacher. Vielleicht ist yagarto etwas für dich? Da gibt es sogar ein fertiges Tutorial für deinen uC. Dein JTAG-Adapter muss halt unter OpenOCD laufen .... Der Startup-Code im Tutorial ist noch recht übersichtlich.
also irgendwie steh ich der arm-programmierung noch etwas skeptisch gegenüber (wobei ich denke das wenn man die anfänglichen probleme überwunden hat die teile einfach nur geil sind, aber muß das soo kompliziert sein ?!) -------- Kenn ich dieses Gefühl..... seufz PS: Bei Rowley müssen dem Preprozessor diverse Direktiven übergeben werden, damit er den Startup Code modifiziert. Sie auch FAQ von Rowley.
@tilo aso ... wusste nicht das der startup-code von rowley selbst ist. mmh. jedenfalls erklärt es sich somit warum der bei adresse 0xa5000001 nur abstürzen kann. da liegt das virtuelle nirvana. werde mir wohl für jedes projekt den startup-code etwas modifizieren müssen. wohl nochmal eine frage zu 2/3 problem(ch)en : - warum muß ich jedesmal das board spannungslos machen um es neu programmieren zu können ? sobald ich das debuggen stoppe und das programm neu flashen möchte kommt entweder "cannot stop device", "verify failed", "device not in debug-mode (oder so ähnlich). erst nach trennen und wiederanschalten von vcc läufts. - wie bekomme ich das programm dauerhaft ins flash ? ich hab schon alles auf flash gestellt was auf flash zu stellen war. muß ich dem flash_placement.xml explizit sagen das das data (als program-code) segement bei 0x00100000 anfängt ? - rowley lädt immer die loader.elf zuerst in den uC. kann es sein das dieser loader nach trennen der versorgungsspannung zwar noch da ist, aber mein programm selbst nicht ?! bin da irgendwie verwirrt. oder brauche ich den loader nicht unbedingt ? danke und gruß rene
@chrisitan danke für dein mitfühlen und die hinweise. werd ich mal durchblättern.
Das Problem mit dem dauernden Reset habe ich bei einem anderen uC auch. Ist wohl einfach so. Zu den ARM7 von Atmel kann ich nichts sagen. Das Problem mit dem Programm im Flash hatte ich auch. Der Grund warum das Rowley so macht ist recht simpel. Mein aduc7000 ist regelmäßig vom Flash losgerannt, auch wenn er am JTAG hing. Das ging Teilweise so weit, dass der uC an JTAG gar nicht mehr erkannt wurde. Nach dem Löschen des Flash mit dem ADI Tool ging er wieder. Schau dir mal die Support-Seite von Rowley an, da steht im Forum wie das Programm im Flash bleibt. War glaube ich eine Linker Option oder so. Ansonsten ist der Support von Rowley nicht schlecht, auch wenn du nur eine Demoversion hast.
Hallo, das gleiche Problem habe ich derzeit auch: Ich kann keine "Release" Version erzeugen, also habe ich alles auf Release gestellt was geht. Der uC rennt einfach nicht los, wenn ich den Stecker abziehe. Auf der Support Seite von Rowly steht aber, dass selbst dazu wieder eine Direktive eingegeben werden muss. Der Startup Code scheint nicht fix zu sein sondern je nach Erfordernissen automatisch geändert zu werden. Da ich eh nicht verstehe was darin passiert lasse ich auch die Finger davon. Erste Falle nach der Installation von 1.7 war der Einsprungpunkt reset-handler. Den konnet ich nirgends finden, wusste auch nicht was machen. Daher habe ich den auf 0x0000000 gesetzt, dann linkte er einwandfrei durch. http://ccgi.rowley.co.uk/support/faq.php?do=article&articleid=52 Das probiere ich heute abend mal aus, hoffe dass er dann auch losläuft, wenn ich den JTAG ab habe. PS: Ich habe mir mal die libmem angeschaut...... Wahnsinn was man mit dem uC alles machen kann. Jedenfalls hat der ARM7 schon so einen kleinen Su8chtfaktor, auch wenn ich derzeit viel länger brauche als beim PIC, weil ich alles nachschlagen muss und diese Bitschieberei einfach nervig ist, weil man keine structs über die Register legen kann. Gruss, Christian
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.