mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ARM9 lässt sich nicht programmieren.Board aber benötigt für Bachelor


Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi an alle!!!

Ich habe ein großes Problem und bin mittlerweile Ratlos...

Ich habe ein selbst entwickeltes Board mit einem ARM9 von STR 
(STR911FAM44X6). Zum programmieren habe ich einen Olimex ARM-USB-OCD, 
der über einen Adapter von 20pin auf 14pin JTAG auf mein Board geführt 
wird. Meinen Code schreibe ich in CrossWorks for ARM.

Bis vor ein paar Tagen hat alles wunderbar funktioniert! Ich konnte 
programmieren was das Zeug hält. Dann eines Tages ging es plötzlich 
nicht mehr und CrossWorks meldet bei sämtlichen lesenden oder 
schreibenden Operationen nur noch:

"cannot halt target after reset"

Connecten kann ich mich hingegen noch problemlos und CrossWorks zeigt 
auch an, dass es sich um eine ARM966E-S Architektur handelt.

Was ich bis jetzt gemacht habe:
- Mit dem Oszilloskop sehen die Flanken am JTAG sauber aus.
- Die Kabellänge vom Programmer zum Board habe ich auch schon drastisch 
reduziert, aber auch keine Besserung (aktuell ca. 10cm).
- Der Quarz auf dem Board schwingt mit 16MHz wie er soll
- 3,3V und 1,8V liegen sauber überall an
- Verbindungen zwischen JTAG-Port und Beinchen vom Controller sind auch 
da
- Den Programmer habe ich mit einem Headerboard mit einem NXP LPC2148 
getestet und es ging auf anhieb (auch mit CrossWorks)
- ARM9 getauscht

Mehr kommt mir gerade nicht in den Kopf...

Das komische ist halt, dass es ja schon seit mehr als einem Monat 
funktioniert hat und mit einem mal nicht mehr. Dabei lief das Programm 
auf dem heruntergenommenen ARM9 ganz normal, er ließ sich "nur" nicht 
mehr programmieren. Der fabrikfrische ARM9 verspürrt auch nicht den 
Drang dazu sich programmieren zu lassen. Immer nur das "cannot halt 
target after reset"

Da ich das Board für meinen Bachelor benötige wäre es super, wenn ihr 
mir eure Ideen mitteilt, was ich noch tun könnte.

Besten Dank schon mal für alle Antworten!!!

Gruß,
Sören.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich tipp mal drauf, daß irgendetwas an ESD gestorben ist. Gibt es noch 
andere Sachen auf dem Board, die da hineinspucken können - irgendwelche 
Supervisor-Schaltungen oder so?

Und: Tausch mal den JTAG-Adapter. Einfach mal so. Nicht daß da irgendein 
Ausgangstreiber etwas abbekommen hat. Das ist nur so eine Ahnung. 
Vielleicht hat noch jemand in Deiner Umgebung ein geeignetes Teil.

fchk

Autor: Sören S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Danke für die Antwort.

Morgen kriege ich mit etwas glück noch einen anderen Programmer, mit dem 
werde ich es dann auch mal versuchen.
Der JTAG ist direkt nach außen geführt, sind nur ein paar 
Pullup-Widerstände vorhanden, die sind aber auch alle heile. Anbei mal 
die JTAG-Schnittstelle.

Gruß,
Sören.

Autor: Stefan Kunz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versuch mal den ClockDivider hochzusetzen und die Geschwindigkeit zu 
drosseln. Das könnte helfen. Eventuell die neusten FTDI Treiber 
runterladen für deinen Programmer.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1k am JTAG finde ich aber ziemlich niedrig. Ich hätte da eher 10k 
genommen, und beim STR910-EVAL sind das auch 10k Widerstände.

AN2339 sagt dazu:
"The recommended value for pull-ups and pull-downs is 10kΩ, although the 
optimum value depends on the signal load. For example, pull-downs should 
be about 1kΩ when working with TTL logic."

Mit TTL arbeitest Du ja wohl hoffentlich nicht mehr, und der Olimex wird 
auch keine TTL-Treiber drin haben. Also mach da mal 10k überall am JTAG 
rein und probiere nochmal.

Edit: Und wenn es dann noch nicht geht, arbeite mal die gesamte AN2339 
komplett durch und schau, ob Du alles so gemacht hast, wie es da steht.

fchk

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke auch dir für deine Antwort!

Habe gerade mal die neusten Treiber runtergeladen und neu gestartet, 
aber noch genau der selbe Fehler... Connecten ja, flashen usw. leider 
nein. Auch der ClockDivider hat keine Auswirkung, habe den dauerhaft auf 
10 stehen und damit hat es auch zuvor immer funktioniert, habe dann auch 
Werte bis 50 durchprobiert und bis 200 auch sporadisch, aber leider auch 
keine Chance...

Gruß,
Sören.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke dir für den Tipp Frank!

Werde die Widerstände morgen mal tauschen und mir das AN2339 
verinnerlichen und bescheid geben!

Gruß,
Sören.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sooooo,

ich hab mir gestern und heute noch das AN2339 angeschaut und das sieht, 
bis auf die 1kOhm Widerstände statt 10kOhm am JTAG alles gut aus. Habe 
die Widerstände aber noch nicht getauscht, da ich gerade noch in der Uni 
sitze. Nachher hol ich mir von der Arbeit noch ein anderen Programmer 
und ein ARM9 Board von Olimex mit einem STR912, dann kann ich noch ein 
bisschen weiter testen...

Habt ihr sonst noch Ideen? Das komische ist wirklich, dass es von einem 
auf den anderen Tag nicht mehr ging... Was eigentlich für ESD spricht, 
aber ich habe den ARM9 ja auch schon getauscht... und der Programmer 
funktioniert auch an einem anderen Board...

Alles sehr mysteriös, aber dank eurer Tipps wird der Kopf noch nicht in 
den Sand gesteckt und alles ausprobiert!

Gruß,
Sören.

Autor: schablonski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi,

hast du schon das massepotential gecheckt, vielleicht "schwebt " die 
masse ja? benutzt  du noch das gleiche netzteil-potentialtrennung 
etcetc?
da es ja nur wenige leitungen sind zwischen jtag und cpu ,würd ich die 
mal auf die schnelle nachlöten.

Autor: Drehender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ansonsten häng dich mal mit nem Logic Analyser ran...

Dann siehst du schnell ob sich auf der Leitung was anstädiges tut.

Anschliessend mal mit ner funktionierenden Kommunikation vergleichen.

Autor: MATLABGURU (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Ich hatte mal ein ähnliches Problem mit diesem Controller. Die Lösung 
brachte mir ein löschen des Flashs mit einem HITEX Debugger. Ein anderer 
funktionierte nicht.

Anschließend hab ich versucht das Problem einzugrenzen. Es lag 
tatsächlich an meinem Code. Bei diesem Controller muss man in einer 
bestimmten Reihenfolge (habs nicht mehr im Kopf) die PLL und clocks 
konfigurieren. Macht man es falsch und spielt den Code auf den 
Controller kann man nichtmehr auf den ihn zugreifen. Wie gesagt, es half 
nur ein Erase mit dem Hitex Teil. Danach konnte ich wieder ganz normal 
weitermachen.

Das war damals mein Problem, vielleicht hilft es ja...

Viele Grüße

Autor: MATLABGURU (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

bei mir war es dieser Controller, habs zu schnell überflogen.

STR912FAW44X6

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Das komische ist ja, dass ich gerade einen fabrikneuen ARM9 auf der 
Platine habe, der noch nie programmiert wurde....
Aber das mit dem Hitex Debugger merke ich mir mal ;)

Gruß,
Sören.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die Fehlerhinweise auf der CrossWorks Supportseite hast du gecheckt?
http://rowley.zendesk.com/forums/51134/entries/45537

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi an alle!

Die Pullup-Widerstände habe ich getauscht, von 1kOhm auf 10kOhm. Bringt 
aber leider auch keine Besserung.

Die Hinweise von der CrossWorks-Seite habe ich mir auch schon zu Herzen 
genommen, das Kabel gekürzt, die Reset-Pins geprüft auf richtige 
Belegung und das richtige Support-Package ist es auch. Den falschen Code 
schließe ich mal aus, da er ja noch nicht programmiert wurde...

Nun werde ich mal schauen ob die Masse vom Programmer auch der Masse vom 
Board entspricht...

Gruß,
Sören.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Masse des Boards und des Programmers sind auch in Ordnung und auf 
dem selben Level..

Gruß,
Sören.

Autor: hp-freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versuchs doch mal mit H-JTAG. Das hat viele Einstellmöglichkeiten.
z.B. Polarität des Reset
Hab zwar keinen STR911xx Controller, aber für meine gings immer...

http://www.hjtag.com/

...
hp-freund

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hp-freund schrieb:
> Versuchs doch mal mit H-JTAG. Das hat viele Einstellmöglichkeiten.
> z.B. Polarität des Reset
> Hab zwar keinen STR911xx Controller, aber für meine gings immer...
>
> http://www.hjtag.com/
>
> ...
> hp-freund

Ehrlich gesagt glaube ich, dass etwas im USB-JTAG Interface kaputt 
gegangen ist. Den uC hast Du ja schon getauscht ohne Erfolg, ein 
jungfraeulicher STR9 sollte sich auf jeden Fall programmieren lassen 
wenn die Hardwaare ansonsten in Ordnung ist, doch die hat ja wohl fuer 
eine Weile funktioniert. Also scheint etwas teilweisse kaputt gegangen 
zu sein. Wie gesagt, ich wuerde auf den JTAG Debugger tippen, doch das 
ist nur meine Meinung nachdem Du schon fast alles andere versucht hast.
Ich wuerde es allerdings eher mit einem JLInk (EDU?) versuchen, den 
kannst Du dann auch hier auf dem Forum "Markt" verkaufen ohne grosse 
Verluste falls Du das Teil nicht magst. Falls der tut und es was 
kommerzielles ist, die J-Link Vollversion ist immer eine gute 
Investition. Funktioniert sehr gut mit Cross-Works und vielen anderen 
Entwicklungsumgebungen.
Gruss, Robert (habe selbst 2 J-Links)

Autor: "gast" (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Löte mal die Lötstellen nach, ich hatte auch öfters das Problem, dass 
defekte Lötstellen probleme machten.
Scahu auch ob es iregndwo auf der Platine kurzschlüsse gibt, die 
irgendwas überlasten und damit den µC stören

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man ich freu mich richtig über die vielen Antworten :)

Ich habe soeben mal die JTAG-Schnittstelle mit dem Logic Analyzer von 
meinem Oszilloskop unter die Lupe genommen, bin gerade dabei die Bilder 
vorzubereiten und dann lade ich sie hoch.

Die Pins des Arms haben wir auch schon 3 mal überprüft immer mit dem 
Ergebnis, dass alles Kontakt hat. Auf Kurzschluss werde ich jetzt noch 
mal testen.

Leider habe ich auf der Arbeit nut einen ARM-JTAG von Olimex ergattern 
können... hab aber leider keinen LPT mehr...
Kann es denn sein, dass mein ARM-USB-OCD noch mit dem NXP LPC2148 
funktioniert, mit dem STR911FAM44X6 nicht mehr?

Gruß,
Sören.

Autor: Sören S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So hier nun die Bilder. Auch wenn sie gerade nicht sehr detailreich 
sind, vielleicht kann ja jemand was auf ihnen erkennen. Das tue ich 
leider nicht, da ich mich selbst noch nicht mit dem Protokoll befasst 
habe...

Die Namen der Bilder stehen für die Aktionen, die ich in CrossWorks 
ausgeführt habe.

Gruß,
Sören.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
An der JTAG-Schnittstelle gibt es auch keine Kurzschlüsse... Auch noch 
mal auf Kontaktierung direkt an den Beinchen gemessen ohne zu drücken 
und es ist überall Kontakt.

Gruß,
Sören.

Autor: hp-freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmen die Einstellungen noch?
FAQ Punkt 3:

http://www.olimex.com/dev/arm-usb-ocd.html

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, die Einstellungen stimmen noch, hab sie an allen 3 Rechnern noch mal 
überprüft.

Gruß,
Sören.

Autor: hp-freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sollte es so einfach sein?
Aus einem anderen Forum:

push the the reset button before programming, helps for me

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider auch nicht ;) War auch mein erster Versuch...

Aber die Verwirrung geht weiter:
Ich habe soeben mit meinem ARM-USB-OCD einen STR912FW44X6 geflasht, der 
die gleiche Architektur wie mein STR911FAM44X6 hat und das funktionierte 
auf anhieb. Allerdings mit dem mitgelieferten 20pin-Kabel. Ich messe nun 
nochmal mein 20 auf 14pin-Kabel durch und dann werde ich mal einen 
Adapter von den 14 zurück auf 20 pins bsteln und schauen ob der STR912 
sich dann immer noch programmieren lässt.

Gruß,
Sören.

Autor: hp-freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hilft leider auch nicht.. Habs gerade mal gemacht, aber immer noch 
"cannot halt target after reset"

Gruß,
Sören.

Autor: hp-freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versuch doch mal die Reset-Steuerung komplett von Hand auszuführen - 
ohne JTAG Verbindungen. An sonsten ist die Adapterprüfung eine gute 
Idee...

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

habe schon ähnliche Probleme mit Luminary Cortex M3 gehabt, was das 
Problem ist, kann ich dir leider nicht sagen, die Lösung bei mir war 
bisher einfach:

Keil U-Link USB J-Tag Debugger tauschen, programmieren, dann hat es auch 
mit dem anderen wieder funktioniert.

lg Heinz

Autor: Sören S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nach einem leckeren Abendessen habe ich weiter gemacht mit der 
Fehlersuche und wie gesagt den Adapter überprüft der von dem 20pin JTAG 
auf meinen 14pin Anschluß geht. Da ich ja das Olimex Board mit einem 
STR912 da habe, habe ich den Adapte, wie vorher gedacht, wieder mit 
Drahtbrücken in das 20pin Kabel "gesteckt" und siehe da, es funktioniert 
mit dem großen Board sofort und macht nicht mal Zicken, obwohl es sehr 
sporadisch gelöst ist...

Da ich natürlich alles invers gemacht habt, anbei noch eine Zeichnung zu 
meinem Kabel. Das hat wie gesagt auch schon die ganze Zeit über 
funktioniert.

Bis auf die Idee mir noch einen weiteren Programmer zuzulegen, z.B. den 
jlink, fällt mir beis jetzt nichts weiter ein.
Der Programmer scheint in Ordnung, das Kabel auch, connecten kann ich 
mich auch, nur kann ich den ARM9 nicht anhalten... (immer dieses "cannot 
halt target after reset"...)

Gruß,
Sören.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum hast Du denn nicht gleich den 20-poligen Stecker auf Dein Board 
gepackt? Der ist für ARM nämlich inzwischen längst Standard.

Die Pinbelegung hat nämlich ihren Sinn - so hat jedes Signal sein 
eigenes Ground, und alle Signale sind schön voneinander getrennt.

Und Dein Pinout sieht auch nicht so aus wie das Standard-ARM. (siehe 
http://infocenter.arm.com/help/index.jsp?topic=/co...)

Ansonsten  ... hmm sorry, meine guten Ideen sind alle schon 
aufgebraucht.

Guten Morgen.

fchk

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen an alle.

Bei der gesamten Platine handelt es sich um eine Avionik für einen 
Quadrokopter. Von den Schnittstellen her habe ich mich an mikrokopter.de 
gehalten, um die Platine so zu gestalten, dass man sie eins zu eins 
gegen die anderen Platinen austauschen kann. Daher resultiert auch der 
JTAG, der völlig aus der Norm fällt. Das war mir auch vorher bewusst und 
ich konnte ja bis zum letzten Wochenende fleißig programmieren was das 
Zeug hält...

Ich habe gesehen, dass es bei segger.com den J-Link EDU für rund 62€ 
inkl. Versand gibt. Kann man den direkt bei denen bestellen? Weil das 
wäre dann noch ein Versuch wert, bevor ich den ARM9 noch mal von der 
Platine hole, um deren Beschädigung zu vermeiden.

Gruß,
Sören.

Autor: Wunsch H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Sören,

hier noch eine Möglichkeit, hat bei mir zum Erfolg geführt.
Warteschleife am Anfang in main(), danach erst die Initalisierung des 
STR9.
Eventuell ist der Debugger zu langsam für den STR9. Das ganze im Release 
Mode wieder entfernen.


int main()
{
Delay(0xFFFF); // Warten auf Reset vom Debugger !!! entfernen im Release 
Mode !!!

str912_init(); // Initialisierung des STR9


........Source Code.............

}

gruss heiko

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Heiko!

Das doofe ist ja, dass ich immer noch einen "jungfräulichen" ARM drauf 
habe, der noch nicht einmal programmiert wurde und sich auch irgendwie 
nicht programmieren lassen will... Dann müsste es ja wenigstens einmal 
klappen, bevor er zu schnell für den Debugger ist oder?

Gruß,
Sören.

Autor: Henrik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du den ARM schon getauscht hast, scheidet der ja aus als 
Fehlerquelle.

Hast du alle Pins, die definiert werden müssen, per PullUp / PullDn 
definiert? Manche Prozessoren haben z.B. MasterInterrupt Pins. Wenn du 
die nicht definierst, läuft der auch nur dann und wann.

Ein Schaltplanauszug von deinem ARM9 wäre hilfreich.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kauf dir den Segger J-Link bevor du weiter rumprobierst. OpenOCD ist 
Schrott.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hendrik!

Den Schaltplan mach ich nachher mal fertig (ich denke es wird heute 
Abend) und lade ihn dann hoch.

Mir ist gerade noch eine Idee unter der Dusche gekommen... Ich hab von 
mikrokopter.de auch eine NaviCtrl, auf der der gleiche ARM werkelt. Ich 
werde also einfach mal den nicht genormten JTAG ( ;) ) mit einer 
Stiftleiste versehen, meinen Programmer anhängen und einfach mal auf 
Stopp in CrossWorks drücken. Mal schauen was dann passiert... Aber auch 
das erst heute Abend... Nun ist erstmal Uni angesagt.

Gruß,
Sören.

Autor: foo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

kennemich nur mir MIPS/JTAG aus, dort bedeutet der fehler code aber, 
dass sich die cpu schon in den ersten cycles aufhängt und dann der jtag 
nich halten kann.

dies ist der fall bei corrupten bootloadern.

ich klemmein solchen fällen den flash ab (entweder physikalisch oder 
kurzen mit schraubendreher provozieren), damit der SoC beim booten 
garnicht erst einen corrupten bootloader laden kann. nicht sicher ob 
dies dein problem ist oder nicht.

greetz

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@...

Ich nutze nur den ARM-USB-OCD als Hardware, programmiert wird mit 
CrossWorks.
Kann ich den Segger J-Link denn direkt bei Segger.com bestellen?

Gruß,
Sören.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja kannst du.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@foo

Hab leider keinen externen Flash drauf.... nur den ARM...

Gruß,
Sören.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den J-Link hab ich nun schon mal bestellt! Unnütz wird der bestimmt 
nicht sein und die Kosten halten sich für einen Studenten mit 62€ ja 
noch in Grenzen. Nachher wird dann weitergetestet.

Gruß,
Sören.

Autor: SEGGER - Til Stork (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Sören,

klar kannst du denn J-Link EDU direkt bei uns bestellen, wo auch sonst? 
;-)

Aber hast du ja anscheinend auch schon gemacht, ich hoffe du kommst 
damit bei deinem Projekt weiter!

Gruß,
Til

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sooooo, mal wieder ein weiterer Test und diesmal mit einer neuen 
Erkenntnis!

Ich habe auf meiner naviCtrl von mikrokopter den JTAG mit einer 
Stiftleiste bestückt, diese Platine hat den gleichen Controller und die 
gleiche Schnittstelle. Also meinen Programmer angeschlossen, mit Strom 
versorgt und anschließend mit CrossWorks connected. Soweit klappt alles, 
genau wie bei mir. Dann habe ich einfach mal auf Stopp gedrückt und 
siehe da, wie bei mir:

"cannot halt target after reset"

Und bei der Platine bin ich mir 100%ig sicher, dass es funktioniert, 
weil ich sie auch schon mal neu programmiert habe, die Stiftleiste dann 
aber wieder aus Platzgründen abgenommen habe.

Also denke ich, dass mein ARM erstmal draufbleiben kann und ich auf den 
J-Link warte! Hoffentlich kommt er schnell an :)

Weiß sonst jemand, was in dem Olimex ARM-USB-OCD für Technik drinsteckt? 
Vielleicht ist er einfach verwirrt und mag den str911 nicht mehr, aber 
jeden anderen?

Gruß,
Sören.

Autor: Henrik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Sören,

was ist mit dem Schaltplanauszug?

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohha.... stimmt da war was, danke für die Erinnerung!

Gruß,
Sören.

Autor: Sören S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, nun aber!

Gruß,
Sören.

Autor: Henrik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Sören.

1) Der VBAT Pin muss an 3.3V angeschlossen werden. Da sagt das 
Datenblatt auf Seite 61:
The VBATT pin should be connected to VDDQ if no battery is installed

Also auf 3.3V setzen. Ob das dein Problem beseitigt, wage ich allerdings 
zu bezweifeln...

2) Die Feedback Widerstände für die Regler sind gefühlt zu klein. Beim 
1,8V Regler ziehst du von Haus aus schon 8mA nach Masse. Find ich ganz 
schön doll, stimmt aber laut Datasheet von National.

Das mit dem VBAT Pin solltest du nachziehen.
Schonmal den Support von STM gefragt?

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen!

Das komische ist ja, dass ich die Platine, die direkt von mikrokopter 
kommt, mit dem gleichen ARM, mit der gleichen Beschaltung, auch nicht 
programmieren kann, es aber schon mal mit den gleichen Adapter und 
Programmer gemacht habe... Ich habe dem Olimex ARM-USB-OCD gestern noch 
mal den EEPROM neu geflasht, aber auch ohne Wirkung, er programmiert 
immer noch alles, bis auf den str911...

Und mit den Pullups vom I2C, I = U/R dann habe ich doch I = 5V / 1000Ohm 
= 0,005A = 5mA und bei 3,3V I = 3,3V / 1000Ohm = 0,0033A = 3,3mA und 
hätte ich 1,8V I = 1,8V = 0,0018A = 1,8mA. Oder stimmt bei meiner 
Rechnung was nicht.... noch zu früh am Morgen ;)

Gruß,
Sören.

Autor: Henrik J. (henrikj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deine Rechnung ist prima.

Die Widerstände sollen aber nur PullUp Widerstände sein, um einen pin zu 
definieren und nicht um ihn schon stark in eine Richtugn zu lenken.

Bei einem niederohmigen PullR werden deine Ausgangsstufen evtl. schon 
gar nicht mehr voll aussteuern. Musst mal schauen, ob der LowPegel 
wirklich auf 0.0V geht, oder vllt schon vorher wegbricht. Der LowLevel 
kann dann z.B. bei 0.3V stehen bleiben. Funktioniert zwar, geht aber 
besser.

Manche Leute bauen zum Beispiel vor ihren uC Pin noch nen 1k Widertand. 
Wenn du der Leitung dann noch nen 1k Pull Widerstand baust, hast du nen 
hübschen Spannungsteiler.

Merke:
Pull Widerstände sollten mit 10k oder 4k7 ausgelegt werden.

Das löst dein Problem übrigens nicht, sondern ist nur ne 
Wissenserweiterung. ;)

VBAT Pin schon mkt 3.3V verbunden?

EDIT:
Ich hatte übrigens auch schon mal nen ARM9 Core, der sich nicht anhalten 
ließ. Das war ne Krankheit vom Debugger, ARm Core und der SW.

Was da half:
Man konnte sich auch mit dem Core verbunden, indem man beim connecten 
eingestellt hat, "No Reset, No Stop". Dann war man schonmal drauf. 
Danach per Kommandozeile reseten. Dann meldet der "Cannot halt 
processor". Nochmal "reset" per Kommandozeile und das Ding fängt sich 
wieder.
Schau mal, ob du nen anderen Connect Mode findest.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ne, VBAT hab ich leider noch nicht mit 3,3V verbinden können. Mein 
heimischer Lötkolben ist dafür leider nicht geeignet, muss ich dann mal 
im Büro machen.

Kannst du das mit der Kommandozeile reseten noch mal näher erläutern, 
was man dazu braucht und wie das geht?

Gruß,
Sören.

Autor: Henrik J. (henrikj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Kommandozeile gab es in meiner Debugger SW. Damit ist nicht die 
Windows kommenadozeile gemeint. Schau mal, ob es so etwas in deinem 
XWorks gibt.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

hab mich mal auf die Suche nach solch einem Terminal gemacht, aber 
leider nichts derartiges in CrossWorks gefunden...

Weiß jemand von euch, wie ein Stop über den JTAG dem Prozessor 
signalisiert wird?

Gruß,
Sören.

Autor: Henrik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du eigenbtlich schonmal versucht mit nem anderen Rechner auf den 
ARM raufzukommen. Wenn alle logischen Dinge nichts mehr bringen, muss 
man die unlogischen untersuchen...
Vllt hat sich das XWorks ja irgendwie ins Nirvana geschossen...

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nabend!

Das war meine aller erste Hoffnung, aber auf allen drei Rechnern, auf 
den es funktioniert hat, lief's schlagartig nicht mehr...

Gruß,
Sören.

Autor: Thomas R. (tinman) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also :
- nicht OS es sei den hast auf allen 3 rechner die gleiche updates für 
OS installiert oder gleich software
- nicht der ARM, da ein anderer auch nciht funktioniert
- nicht der JTAG kabel da mit andern µC/boards funktioniert.


Ich denke es wird der jtag sein, als bei meinem H-jtag usb ein buffer ic 
gestorben war, konnte ich denoch zum arm7 verbinden/arbeiten, aber nicht 
zum arm9/cortex m3 (wobei arm9 ähnlich wie bei dir verbindung da aber 
kein upload, kein debug,  kein externes flash usw, beim cortex hat der 
tap nur unsinn gezeigt).

Jetzt muss du nur abwarten bis der j-link da ist und hoffen das es doch 
nciht ein hidden os update alle 3 rechner "gekillt" hat

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum Glück ist sinds auch unterschiedliche OS, einmal Mac OS X und 
zweimal Windows ;)

Gruß,
Sören.

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

die Konsole im CrossWorks befindet sich im Javascript Fenster. Wenn du 
dort Befehle mit "TargetInterface." benutzt, kannst du das JTAG steuern 
bzw. den Controller.

Schau dir mal dein "Reset"-Script an, da stehen ein paar Befehle drin.
(und UserManual)
Beispiel (At91):
 TargetInterface.setMaximumJTAGFrequency(32768);
 TargetInterface.pokeWord(0xFFFFFC20, CKGR_MOR_VAL);
 TargetInterface.delay(10);

mfg
Stephan

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Abend!

Ich habe es heute noch mal mit einem anderen USB-Programmer von Olimex 
versucht (ARM-USB-TINY), aber auch mit dem kam das selbe Ergebnis...

Die Script-Konsole in Crossworks habe ich auch gefunden und mal mit 
rumgespielt. Manchmal sah es so aus, als ließe sich der Prozessor 
stoppen, aber beim Programmieren kam wieder der gleiche Fehler (cannot 
halt target after reset). Sobald man hingegen ein Board anschließt, 
welches keinen str911 trägt, funktioniert es wieder 1a. In einem anderen 
Forum stand, dass jemand die gleichen Probleme mit einem NXP Arm7 hatte. 
Da wurde das Problem gelöst, indem der JTAG ClockDivider auf 30 und der 
Stop Timeout auf 30000ms gestellt wurde, bringt aber leider auch 
nichts... Anschließend habe ich mir noch das Script angeschaut, dass 
während dem Reset ausgeführt wird.

TargetInterface.resetAndStop(1);

Diese Funktion löst den Fehler aus, auch wenn man ihr den Wert 30000 
mitgibt (30 Sekunden warten nach Reset bis zum Stop), gibt es den 
gleichen Fehler.

Morgen werde ich das ganze mal mit einem Programmer über den LPT-Port 
versuchen. Ich denke beim TINY hat es auch nicht geklappt, weil er auf 
dem gleichen Chip (FT2232) basiert, wie der ARM-USB-OCD. Mit etwas Glück 
kommt morgen auch schon mein J-Link an :)

Gruß,
Sören.

Autor: Henrik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Sören,

dann drück doch mal in das Script die Funktion
TargetInterface.NoResetAndNoStop(1)
wenn es die gibt. KA wofür die 1 steht. Erstmal rauf auf den Prozessor 
und dann nochmal per Script 2x reset hinterherschicken. Vllt fängt er 
sich dann wieder.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Tag!

Ich bin vielleicht mal endlich ein Stück weiter gekommen!!!

Ich sitze gerade an einem älteren Rechner, der sogar noch einen echten 
LPT-Port hat :) Dort hab ich dann mal einfach einen Wiggler (Olimex 
ARM-JTAG) angeschlossen und siehe da, es kommt schon mal keine Meldung 
mehr mit "cannot halt target after reset"! Dafür aber folgendes (ich 
habe die Ausgabe von Crosworks mal einfach kopiert)

Checking “myFlightCtrl” in configuration “ARM Flash Release”
Preparing target for download
  Loading target script file STR91x_Target.js
  Executing reset script FLASHReset()
Downloading “Loader_512_bb0_rpc.elf” to Macraigor Wiggler (20 Pin)
  Programming completed in 3.4 s — 893 bytes/sec
    Programming 2.9 KB of addresses 04000000 — 04000bb7
Verifying “Loader_512_bb0_rpc.elf” on Macraigor Wiggler (20 Pin)
  Verifying completed in 4.2 s — 716 bytes/sec
    Verifying 2.9 KB of addresses 04000000 — 04000bb7
Erasing “myFlightCtrl.elf” to Macraigor Wiggler (20 Pin) — 1 error
  Erasing — 1 error
    Erasing 41.7 KB of addresses 00000000 — 0000a713
    Erase failed
  Preparing target for user application
    Loading target script file STR91x_Target.js
    Executing reset script FLASHReset()

Der Loader wird nun schon mal Übertragen! Soweit gings vorher ja noch 
nicht mal. Nun happert es aber beim Löschen des Speichers und unten in 
der Leiste taucht nun die Fehlermeldung "Memory erase operation failed: 
memory is locked" auf. Habe versucht den separat über den Menüpunkt 
"Erase all..." zu löschen, aber dann kommt die gleiche Meldung. Hat 
jemand da eine Idee an was es liegen könnte? Da ich den Controller ja 
immer noch nicht programmieren konnte, dürfte der Speicher des 
Controllers doch auch eigentlich nicht geloggt sein oder?

Gruß,
Sören.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fast vergessen...
@Hendrik:

Die Funktion gibt es leider nicht, wenn ich das
TargetInterface.resetAndStop(1);
herausnehme, dann geht auch gar nichts mehr ;) also zu brauchen scheint 
er diesen Eintrag im Reset-Script auf alle Fälle.

Gruß,
Sören.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmmmm,

gerade habe ich noch mal auf "Unlock all..." gedrückt und da stand dann, 
dass die Operstion erfolgreich ausgeführt wurde, aber beim 
Programmierversuch stand dann wieder, dass der Memory gelocked ist...

Gruß,
Sören.

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann es vielleicht sein, dass etwas mit einer der Versorgungsspannungen 
nicht stimmt?
Eventuell ist eine Löschoperation am Flash (die ja vor jedem Beschreiben 
ausgeführt wird) durch einen Versorgungsspannungsfehler unterbrochen 
worden und einige Flashzellen befindet sich jetzt in depletion.
Gibts bei dem Prozessor eine Flash depletion-recovery?

Grüße,

Peter

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter!

Habe in den Datenblättern leider nichts derartiges gefunden... Meine 
Spannungsversorgungen mit 1,83V und 3,35V sehen auch auf dem Oszilloskop 
sauber aus. Kann es auch daran liegen, dass man einfach mal den Strom 
zwischendurch weggenommen hat? Aber als ich das die Tage gemacht habe, 
ist er noch nicht mal bis zur Löschoperation gekommen, den Teilerfolg 
konnte ich erst heute erzielen und habe aus Freude auch einfach mal den 
Strom dauerhaft dran gelassen ;)

Gruß,
Sören.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
BTW, kannst du mir das Wort "depletion" näher erklären? Man lernt ja nie 
aus :)

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kenne das nur von den TMS320 mit internem Flash.
Wenn ich es richtig verstanden habe, ist es ein Fehler, der auftritt, 
wenn man das Flash mit dem falschen Timing löscht.
Wenn man das Flash beispielsweise in system löscht und den 
Flashcontroller mit dem falschen Takt konfiguriert, kann das passieren.

Es kann auch passieren, wenn eine Löschoperation ausgeführt wird und 
diese aus irgendeinem Grund zum falschen Zeitpunkt unterbrochen wird. 
Bei Stromausfall wird normal der Takt gesperrt und wenn in diesem Moment 
gerade gelöscht wird, liegt die Löschspannung an einer einzelnen 
Flashzelle so lange an, bis die Spannung ganz weg.

Das Wesentliche daran ist wohl, dass die Löschspannung zu lange an einer 
Flashzelle anliegt, wodurch diese depletion hervorgerufen wird. Die 
Hersteller bezeichenn diesen Zustand auch teilweise als "over-erased".
Ist das der Fall, kann die Zelle nicht mehr programmiert werden (Bits 
können nicht auf 0 gesetzt werden).

Es muss dann eine "depletion-recovery" ausgeführt werden, was relativ 
viel Zeit in Anspruch nimmt. Befindet sich das Flash in 
"deep-depletion", ist kein recovery mehr möglich, das Flash ist dann 
zerstört. Das soll durch einen normalen Stromausfall nicht erreichbar 
sein. Bei falsch konfiguriertem Flashcontroller kann es aber angeblich 
passieren.

Wesentlich an diesem Fehler ist, dass pro falschem Löschvorgang immer 
nur ein Sektor kaputt geht, eben der, der zum Taktausfall gerade 
gelöscht worden ist.

Ich würde also mal von Hand testen, welche Sektoren sich nicht 
beschreiben lassen.

Grüße,

Peter

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht hat es ja etwas mit dem nicht angeschlossenen VBAT zu tun. 
Das würde ich auf jeden Fall als erstes richtig anschließen.

Kannst du eigentlich Programme in das RAM laden und dort laufen lassen?

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als nächsten Versuch würde ich auf allen Spannungsreglern sowohl am 
Eingang als auch am Ausgang zusätzlich 100 nF so nah wie möglich an den 
Regler bauen. Das sollte man eigentlich immer so verblocken, viele 
Regler neigen sonst zum Schwingen.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich eine Aktion ausführe, dann lädt er immer zuerst den JTAG-Loader 
in den RAM und verifiziert diesen. Das klappt auch wunderbar mit dem 
Wiggler. Nur das Programmieren in den Flash will nicht....

Ich habe nun mal wie du sagtest per Hand die Zellen gelöscht. Von der 
Adresse 0x00000000 bis 0x03FFFFFFFF, das ist der gesamte Flash und das 
ging ohne Probleme... aber auch danach lässt er sich nicht 
programmieren...

Die Spannungen schwingen nicht, hab ich auch schon mit dem Oszilloskop 
überprüft...

VBAT muss ich am Montag auf der Arbeit mal testen, aber vorher ging es 
ja auch ohne... alles sehr komisch ;)

Gruß,
Sören.

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, jetzt hab ich mal im Datenblatt gelesen.
Es gibt physikalisch zwei Chips in dem Gehäuse. Das eine ist die CPU und 
das andere das Flash. Beide sind seriell am JTAG angeschlossen.

Programming 2.9 KB of addresses 04000000 — 04000bb7
Das ist ein RAM-Adressbereich, das liegt in der CPU.
Das sagt uns, dass über JTAG das RAM beschreiben werden kann.

Verifying 2.9 KB of addresses 04000000 — 04000bb7
Das sagt uns, dass die Daten aus dem RAM auch korrekt wieder ausgelesen 
werden können. Dabei werden sie durch den JTAG Controller des Flash 
unverändert durchgeschickt.

Insgesamt sehen wir, dass das JTAG Interface korrekt funktioniert, sonst 
wäre der Verify fehlerhaft.

Erasing 41.7 KB of addresses 00000000 — 0000a713
    Erase failed
Das ist ein Flashadressbereich.

Das hört sich sehr nach einem sequentiellen Page-Erase an. Ich würde mal 
einen Chip-Erase probieren, der löscht nämlich zusätzlich alle security 
fuses, die ein normales Page-Erase verbieten können.

Grüße,

Peter

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Die Spannungen schwingen nicht, hab ich auch schon mit dem Oszilloskop
>überprüft...

Ist das auch während einem Page-Erase nachgemessen?

Autor: Pothead (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sören S. schrieb:
> Habe in den Datenblättern leider nichts derartiges gefunden... Meine
> Spannungsversorgungen mit 1,83V und 3,35V sehen auch auf dem Oszilloskop
> sauber aus.

Hast du die während des Flash-Zugriffes angeschaut? Stell den Offset vom 
Scope so ein, dass die Spannung im Ruhezustand auf 0 liegt und zieh die 
Vertikale Auflösung so weit wie möglich auf - dann versuche zu 
programmieren und beobachte was passiert. Achte auf eine möglichst kurze 
Masseanbindung!

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke mal der Chip-Erase fällt unter den Punkt "Erase All" oder?
Weil wenn ich das versuche, dann kommt die Fehlermeldung... Wenn ich 
hingegen nur den Bereich des Flashes angebe, dann gehts.

Wenn ich angeben würde, dass ich 0x00000000 bis 0x80000000 löschen 
möchte (der gesamte Adressbereich) kann dann irgendwas schief gehen oder 
kann man das ruhig machen?

Ich denke mal, dass sich der verdächtige Bereich irgendwo zwischen 
0x08000000 und 0x20000000 befindet, der ist Reserved, laut Reference 
Manual Seite 21.

Gruß,
Sören.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hol mal eben das Oskar raus ;)

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde das JTAG “Full Chip Erase” command ausführen.
Wie man da von deiner Software her genau ran kommt, weiß ich nicht.
Im Zweifel würde ich mir ein Programm schreiben, das in das RAM geladen 
wird und das erledigt.

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt da auch noch einen OTP Speicherbereich, da rein zu schreiben ist 
bestimmt keine so gute Idee.
Ich würde keine Adressen angeben, die als reserved gekennzeichnet sind.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sooo, ich hab nun noch mal während dem Programmierversuch, dem Löschen 
und dem reconnecten geschaut. All diese Operationen haben auf die 1,8V 
und die 3,3V keine sichtbare Auswirkung (bei 50mv auf der Y-Achse).

Gibt es sonst ein anderes Freeware-Tool, das den Full Chip Erase 
durchführen kann?

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde mal bei den üblichen Compilerherstellern (z.B. IAR oder Keil) 
nach codegrößenbeschränkten Testversionen suchen, die Programmiertools 
sollten ja vollwertig sein.

Ansonsten irgendein gnuarm bzw. yagarto Paket runterladen und es mit gdb 
versuchen, das ist aber mit Sicherheit nicht ganz so schnell zu 
erledigen.

Oder so, wie ich schon vorher vorgeschlagen habe:
Mit der momentanen Toolchain ein kleines Programm schreiben, das ins RAM 
geladen wird und von dort das Flash löscht. Das sollte auch gar nicht so 
schwierig sein. Der Vorteil daran ist, dass man die volle Kontrolle über 
alles hat und alles Interessante überprüfen kann. Die gesammelten 
Informationen kann man dann über irgendeine Schnittstelle (z.B. 
txd1_debug) ausgeben.

Grüße,

Peter

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier:
http://www.armbedded.eu/node/47
gibt es ein umfangreiches Beispiel für das Beschreiben von Flashspeicher 
mit OpenOCD.

Grüße,

Peter

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ich hab nun noch mal in Crossworks unter "Erase range..." angegeben, 
dass ich den Flash komplett löschen möchte (0x00000000 bis 0x04000000) 
und anschließend noch den kompletten Ram (0x04000000 bis 0x08000000). 
Was sagt mir Crossworks da: Completed

Nur wenn "Erase all" aufgerufen wird, kommt der "memory is 
locked"-Fehler... Und das auch sehr schnell, also er fängt gar nicht 
richtig an.

Ich hab mir dann noch IAR und Keil runtergeladen, aber die arbeiten mit 
den Programmern einfach nicht zusammen... Morgen kommt dann endlich der 
neue J-Link an, vielleicht bringt der ja ein bisschen neue Hoffnung.

Ich denke ich werde nachher auch mal eine Mail an den Crossworks-Support 
schreiben, vielleicht sagen die mir ja, was bei "Erase all" alles 
getätigt wird und vielleicht haben die ja auch noch eine Idee auf 
Lager...

Ich werde mich vielleicht gleich mal überwinden und werde versuchen 
meine NaviCtrl-Platine von Mikrokopter.de zu löschen. Wenn das geht, 
dann kann man ja schon mal weitere Fehlerquellen ausschließen.

Gruß,
Sören.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmmmmm....

Ich habs eben mal einfach bei meiner NaviCtrl ausprobiert, aber da kommt 
egal mit welchem Programmer der Fehler "Cannot halt target after 
reset"... egal welche Operation man ausführt, aber die Platine selber 
läuft/fliegt.

Gruß,
Sören.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Mittag!!!

Eine neue Erkenntnis!

Ich habe soeben eine weitere Platine so weit bestückt, dass man sie 
Programmieren kann und siehe da, es hat genau 1mal geklappt!!! Nun kommt 
ein "Loader verify failed" Fehler... und ich komme somit wieder nicht an 
den Prozessor ran...
Theoretisch sperre ich mich dann doch über meinen eigenen Code aus oder? 
Die Geschichte mit der Definition der Clock schließe ich eigentlich aus, 
da ich die ganz zum Anfang einmal festgelegt habe und nicht mehr dran 
rumgespielt habe, aber ich werde es trotzdem mal mit den Beispielen von 
STM vergleichen.

Hat jemand noch eine Idee, woran es liegen könnte, dass man sich 
aussperrt?

Heute abend kommt ja endlich der Segger J-Link, vielleicht packt er das 
ja...

Gruß,
Sören.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der J-Link packts auf jeden Fall :-). Da gibt es nämlich extra ein Tool 
"STR91x commander" um notfalls das Flash löschen zu können wenn du ein 
Programm drin hast, was Blödsinn macht.

Autor: Mike J. (emjey)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sören S. schrieb:
> Theoretisch sperre ich mich dann doch über meinen eigenen Code aus oder?

Das hatte ich auch mal mit einem Cypress Controller.
Ich hatte diesen kleinen "First Touche Programmer" und konnte quasi über 
I2C das Teil beschreiben und über ISSP.

Auf dem Targetboard habe ich über I2C Daten ständig gesendet, das muss 
der Grund gewesen sein.
Beim Flashen habe ich zwar auch mal ISSP ausgewählt, das hat die 
Software aber scheinbar ignoriert.

@ Sören
Ich hatte so zwei Targetboards unbrauchbar gemacht, einfach durch eine 
"falsche" Firmware.
Bei mir war die Lösung der Bau eines einfachen, PSoC Parallelport 
Programmers der mir die beiden Chips löschen konnte.

Vielleicht gibt es für den ARM auch einen Programmer mit weniger 
Intelligenz.
... wiggler vielleicht

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde mal untersuchen, welche Möglichkeiten der Codesicherung es auf 
dem Controller gibt. Was genau steht in dem OTP-Speicher? Kann man sich 
per Software dauerhaft aussperren, so wie bei den neuen TMS320F2xxx? 
Dort kann man, wenn man das Flashpasswort komplett mit Nullen 
beschreibt, nie wieder an den Speicher ran, es gibt dann nur noch die 
Option "Auswechselns des Controllers".

Grüße,

Peter

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nabend!

Hab eben mal den J-Link ein bisschen getestet (ausgiebig wird's morgen 
probiert, wenn der Übungszettel für die Uni fertig und abgegeben ist). 
Ich hab dann mal gleich den STR9 Commander geöffnet und "erase all" 
eingetippt. der hat dann erstmal alles geleert und das ohne dabei ärger 
zu machen! Mit dem Einbinden und Programmieren über Crossworks muss ich 
mich dann morgen mal beschäftigen, aber ich bin wieder neuer Hoffnung!

Also noch mal vielen Dank für den Tipp mit dem J-Link!

Ich hab auch noch mal die OTP-Bytes ausgelesen:
Wort 0: FF FF FF FF
Wort 1: FF FF FF FF
Wort 2: FF FF FF FF
Wort 3: FF FF FF FF
Wort 4: FF FF FF FF
Wort 5: FF FF FF FF
Wort 6: FF FF FF FF
Wort 7: FF FF 21 91

Das ist bei beiden Controllern der Fall. Weiterhin steht in den 
Configbytes, dass der gesamte Flash unlocked ist.

Morgen geht's dann weiter!

Gruß,
Sören.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen!

Nach einigem Hin und Her habe ich mich doch entschieden den ARM9 von der 
Platine zu nehmen! War ganz schön nervenaufreibend, aber ein neuer hat 
seinen Platz eingenommen und ist Funktionsfähig! Ich denke bei dem Alten 
war der Flash im Eimer. Zur Sicherheit habe ich auch mein SVN auf eine 
Version vor dem Dilemma zurückgespielt und werde mal vergleichen, was 
sich von dieser Revision auf die andere geändert hat. Wenn ich den 
Fehler gefunden habe, dann werde ich natürlich bescheid sagen.

Euch allen vielen Dank für die reichlichen Ratschläge und Tipps!!! Hab 
ich mal wieder viel bei gelernt und es hat Spaß gemacht :)

Gruß,
Sören.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Abend!

Nun melde ich mich mal endlich wieder. Ich habe das Problem nun 
lokalisiert und es ist wirklich ein Problem mit dem Programmcode, der 
aber eigentlich korrekt ist. Aber dazu Folgendes:

Ich habe die UART0-Schnittstelle an 2 Port-Paaren herausgeführt, einmal 
für Kompass und einmal für GPS.

Kompass-RXD kommt auf Pin 5.1 rein
Kompass-TXD geht auf Pin 5.0 raus
GPS-RXD kommt auf Pin 6.6 rein
GPS-TXD geht auf Pin 6.7 raus

Mit den ersten drei Pins gibt es keine Probleme, die kann ich ganz 
normal über GPIO-Init aus der Bibliothek konfigurieren und sind auch 
funktionsfähig. Sobald ich aber Pin 6.7 als TXD initialisiere geht 
nichts mehr und ich muss einen "erase all" mit J-Link über die Konsole 
machen. Dann kann ich aber wieder programmieren. Wenn ich bei 
initialisiertem Pin 6.7 die Spannungsversorgung aus und wieder 
einschalte läuft der Controller an, aber nur wenn der Programmer ab ist. 
Im Error-Datasheet steht leider nichts über diesen Fehler.

Habs bei beiden Platinen getestet.

Gruß und gute Nacht,
Sören.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sören S. schrieb:

> Ich habe die UART0-Schnittstelle an 2 Port-Paaren herausgeführt, einmal
> für Kompass und einmal für GPS.

Die selbe UART gleichzeitig auf 2 Pin-Paaren???

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin damit vielleicht ein bischen spät dran, aber bei Crossworks klingelt 
bei mir was: Dessen Startup-Code für STR9 initialisiert PCLK auf vollen 
Takt. Dummerweise sind nicht mehr als 48MHz zulässig.

Es kann auch sinnvoll sein, den Startup-Code von ARMs so zu 
modifizieren, dass ganz am Anfang ein Sekundenbruchteil gewartet wird, 
bevor an irgendwas gedreht wird. Einerseits ersetzt das die bei 
Crossworks ebendort etwas störende Totschleife für den Debug-Mode (von 
Rowley als Alternative bestätigt) und kann auch im Release-Code drin 
bleiben, andererseits erreicht man so, dass der Programmer/Debugger 
eingreifen kann bevor der Controller in der Lage ist, ihn auszusperren.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen!

Die UART0 ist einfach auf den beiden Pins rausgeführt um flexibler zu 
bleiben, benutzt wird nun in erster Linie aber nur das Pinpaar für GPS, 
also Pin 6.6 und 6.7, wo letzterer ja dann die Probleme macht.
Mit dem Startup-Code werde ich dann mal schauen wie das geht.

Gruß,
Sören.

Autor: Sören S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Tag!

Ich hab nun, nachdem eine Antwort vom ST-Support kam, die endgültige 
Lösung für das Problem!!!
Komischerweise muss bei diesem Pin 6.7 (TXD0) in der Portdefinition 
explizit die Abteilung für die Input-Funktionen abgeschaltet werden. Das 
simple hinzufügen der folgenden Zeile in die Konfiguration beseitigt das 
Problem, dass man sich über JTAG aussperrt:

GPIO_InitStructure.GPIO_IPInputConnected = 
GPIO_IPInputConnected_Disable;

Bei den anderen Pins muss man dies komischerweise nicht explizit machen. 
Jedefalls funktioniert nun alles wunderbar!!!!

Besten Dank noch mal an alle die hier mit aktiv waren!!! Wie gesagt, war 
sehr interessant und lehrreich!!!

Gruß,
Sören.

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.