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.
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
Angehängte Dateien:
-
jtag.png
9,4 KB
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.
Versuch mal den ClockDivider hochzusetzen und die Geschwindigkeit zu drosseln. Das könnte helfen. Eventuell die neusten FTDI Treiber runterladen für deinen Programmer.
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
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.
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.
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.
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.
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.
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
Hi, bei mir war es dieser Controller, habs zu schnell überflogen. STR912FAW44X6
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.
die Fehlerhinweise auf der CrossWorks Supportseite hast du gecheckt? http://rowley.zendesk.com/forums/51134/entries/45537
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.
Die Masse des Boards und des Programmers sind auch in Ordnung und auf dem selben Level.. Gruß, Sören.
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
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)
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
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.
Angehängte Dateien:
-
connecten.png
5,4 KB -
connected_keine_aktion.png
5,1 KB -
programmierversuch.png
5,9 KB -
stoppversuch.png
5,9 KB -
disconnected_keine_aktion.png
5,1 KB
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.
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.
Ja, die Einstellungen stimmen noch, hab sie an allen 3 Rechnern noch mal überprüft. Gruß, Sören.
Sollte es so einfach sein? Aus einem anderen Forum: push the the reset button before programming, helps for me
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.
Hilft leider auch nicht.. Habs gerade mal gemacht, aber immer noch "cannot halt target after reset" Gruß, Sören.
Versuch doch mal die Reset-Steuerung komplett von Hand auszuführen - ohne JTAG Verbindungen. An sonsten ist die Adapterprüfung eine gute Idee...
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
Angehängte Dateien:
-
jtag20-14.png
21 KB
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.
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=/com.arm.doc.faqs/ka3901.html) Ansonsten ... hmm sorry, meine guten Ideen sind alle schon aufgebraucht. Guten Morgen. fchk
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.
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
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.
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.
Kauf dir den Segger J-Link bevor du weiter rumprobierst. OpenOCD ist Schrott.
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.
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
@... 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.
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.
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
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.
Moin Sören, was ist mit dem Schaltplanauszug?
Ohha.... stimmt da war was, danke für die Erinnerung! Gruß, Sören.
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?
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.
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.
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.
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.
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.
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...
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.
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
Zum Glück ist sinds auch unterschiedliche OS, einmal Mac OS X und zweimal Windows ;) Gruß, Sören.
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):
1 | TargetInterface.setMaximumJTAGFrequency(32768); |
2 | TargetInterface.pokeWord(0xFFFFFC20, CKGR_MOR_VAL); |
3 | TargetInterface.delay(10); |
mfg Stephan
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.
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.
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.
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.
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.
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
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.
BTW, kannst du mir das Wort "depletion" näher erklären? Man lernt ja nie aus :)
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
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?
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.
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.
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
>Die Spannungen schwingen nicht, hab ich auch schon mit dem Oszilloskop >überprüft... Ist das auch während einem Page-Erase nachgemessen?
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!
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.
Ich hol mal eben das Oskar raus ;)
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.
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.
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?
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
Hier: http://www.armbedded.eu/node/47 gibt es ein umfangreiches Beispiel für das Beschreiben von Flashspeicher mit OpenOCD. Grüße, Peter
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.
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.
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.
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.
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
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
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.
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.
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.
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???
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.
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.