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
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
