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
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.
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!
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.
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.
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.
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.
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.
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
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.
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.
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.
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...
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
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):
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.
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
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 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
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.
