www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik At91Sam7 führt Programm nicht (korrekt) aus


Autor: Tobias Schlegel (Firma: none) (tobimc) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich habe hier ein merkwürdiges "Problem":
Ich habe gestern mit meinem (selbstgebauten) ARM-Board gearbeitet 
(Schaltplan im Anhang). Das Board hat bisher absolut spitzenmäßig 
funktioniert. Es gab keine Probleme mit flashen / JTAG uä.
Ich habe es nach P64-Board von Olimex designt.

Gestern wollte ich allerdings den ARM mit einer neuen Firmware flashen:
Dazu verwende ich den USBprog, mit entsprechender Firmware und 
entsprechender openOCD-Version. Geflasht wird über telnet mit
flash write 0 <file> 0x0
Dieses Verfahren hat noch nie Probleme gemacht.
Gestern allerdings begann der ARM wilde Zeichen über RS232 zu senden 
(später dann (je nach Laune) Nullen -> LOW-Pegel). Auch scheint er eine 
Timer-ISR (IRQ, eine ins RAM gespiegelte Funktion(_ramfunc)) nicht 
auszuführen.

Leider kann ich den ARM nicht wechseln, da das Board sonst zerstört 
würde (Pads sind einfach zu dünn).

Geh ich recht in der Annahme, dass der ARM einen ESD-Tod gestorben ist 
(glaub ich irgendwie selber nciht), oder können solche lustigen Effekte 
noch sonst irgendwie auftreten (Sam-BA?)?
Das JTAG-Interface funktioniert übrigens, ich kann den µC Anhalten und 
neu starten.
Allerdings geht das Übertragen der Software schneller als normal, 
nämlich 16 statt normal 18 Sekunden. Dies legt die Vermutung nahe, dass 
der Flash irgendwie hinüber ist...
Ich konnte (leider) keinen Fehler am USBprog/openOCD-System finden...

Habt Ihr eine Idee, oder könntet Ihr mir weitere Diagnoseschritte 
vorschlagen?
Viele Grüße and thanks in advance,
Tobi

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich würde mal das komplette flash samt gpnvm bits löschen (mittels erase 
pin). danach mal ein testprogramm laden (led toggeln o.ä.) und mals 
schauen ob das läuft.

gruss
gerhard

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@tobi:
den schaltplan als pdf anzuhängen ist auch kein fehler.

gruss
gerhard

Autor: Tobias Schlegel (Firma: none) (tobimc) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi

ich hoffe jpeg ist dir auch recht, PDF ist mehr Aufwand.

Die Idee mit dem ERASE-Pin ist klasse.
Ich habe das gerade getestet, der ARM stellt sich zumindest recht 
jungfräulich (LEDs leuchten trübe -> TRIstate).
Ich habe dann versucht mein Testprogramm zu flashen (LED-blinken per 
Timerinterrupt plus RS232-Hello-World).
Leider das gleiche Spiel wie vorher.
Allerdings scheint er die Peripherie zu initialisieren, die LEDs sind 
AUS.
Das würde heißen Startupcode, Initialisierung etc laufen.

Ich werde mal den RAM-Aufruf nacher noch weglassen, aber selbst wenn 
"nur" das RAM kaputt wäre, wäre das ein ziemliches Todesurteil schätze 
ich.
Es ist denke ich am wahrscheinlichsten, dass irgendein Speicher defekt 
ist. Daher auch die schnelle Schreibzeit.

Was denkst Du / Ihr darüber?

VLG Tobi

Autor: tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Tobias: Also wenn der Chip noch so weit tut, dann wird es sehr 
unwahrscheinlich sein, dass das RAM o.ä. tot ist. In den heutigen Chips 
sind Schutzdioden u.ä. eingebaut, so dass der Chip nur noch in sehr 
wenigen  Fällen den ESD-tot stirbt. Ausgeschlossen ist es nicht, aber 
ich würde es in deinem Fall ausschließen. Meist ist derjenige der vor 
dem Chip sitzt das größere Problem! Sorry, ist nicht böse gemeint, die 
Erfahrung zeigt dies aber. Hast Du wirklich alle Fehlerquellen 
ausgeschlossen?

Autor: Jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du die Taktfrequenz zwischen deinen Versuchen verändert und u.U. 
die Waitstates beim Flashzugriff nicht beachtet?

Autor: Tobias Schlegel (Firma: none) (tobimc) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In dem Fall wärs mir (sehr sehr) recht, wenn der Fehler 30cm (in meinem 
Fall hier 50cm) vor dem Bildschirm sitzen würde, das würde mir nämlich 
einen haufen Arbeit ersparen.
Das Problem ist nur den Fehler zu finden ;)

Das Verdächtige ist ja, dass das Problem vom einem Flashen zum anderen 
Flashen auftrat.
Ich habe eine Version der Firmware geflashed, getestet, dann ein paar 
Registereinstellungen am SPI-init verändert (keine Taktgeschwindigkeit 
oä, keine Systemregister verändert), dann den µC angehalten (halt) und 
die neue Firmware geflashed. Mit dem Unterschied, das es diesmal (wie 
gesagt 3 Sekunden) schneller ging als üblich für die 2kb Code (was ja im 
übrigen auch verdächtig ist, da ich die JTAG-Geschwindigkeit nicht 
geändert habe /der USBprog halt so gemächlich ist).

Mein Code baut übrigens auf dem GPIO-Beispiel vom Martin Thomas auf, von 
daher sollte das schon ok sein...

Mich wundert es auch, dass der Chip noch soweit funktioniert... Ich 
werde nacher mal das JTAG-Kabelgedöns durchmessen, evtl. kommt das 
Programm ja nicht richtig an...

hm

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.