www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Langsam lass ich die ARMe hänge.


Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: PeggySue (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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) ?!

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?!)

Autor: Tilo L. (katagia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@chrisitan

danke für dein mitfühlen und die hinweise. werd ich mal durchblättern.

Autor: Tilo L. (katagia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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=articl...

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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.