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

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

@tobi:
den schaltplan als pdf anzuhängen ist auch kein fehler.

gruss
gerhard

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

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

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

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