Ich hab den Post auch ins Seggerforum gepostet, hoffe am Wochenende aber
hier auf schnellere Hilfe :) (Daher auch auch englisch, deutsche
Antworten nehm ich auch sehr gerne).
Hi,
I'm doing my first steps with the J-Link (Edu) and Cortex-M3 (Olimex
STM32-H103, with an STM32F103RB onboard).
After having many, many, problems (which were all caused by myself), I'm
stuck at this error message, given by Keil µVision4.
I wonder what "Core is locked-up" means. I've already tried the STM32
Unlock utility, which gives nothing but OKs back to me.
Yours,
CowZ
1
Load "[...]\\Obj\\Gpio.AXF"
2
JLink info:
3
-----------
4
DLL: V4.10i, compiled Jan 25 2010 14:43:57
5
Firmware: J-Link ARM V8 compiled Dec 1 2009 11:42:48
6
Hardware: V8.00
7
S/N : 268000075
8
OEM : SEGGER-EDU
9
Feature(s) : FlashBP
10
---
11
* JLink Info: TotalIRLen = 9, IRPrint = 0x0011
12
* JLink Info: Found Cortex-M3 r1p1, Little endian.
"Unlock utility" klingt nach einem Tool, das geschützte Flash-Pages
entsperrt.
"Core is locked-up" klingt hingegen nach einem per JTAG nicht mehr
ansprechbaren Cortex-Core (d.h. JTAG geht prinzipiell, aber dann ist
Schluss), und nicht nach Flash-Problemen.
Schon versucht, das Device per Bootloader zu löschen?
Hallo,
erstmal die schlechte Nachricht: Das Runterschrauben der JTAG-Frequenz
hat nichts gebracht.
Jetzt die (super duper) gute Nachricht: Das Löschen des Devices per
Bootloader hat geholfen! Jetzt konnte ich per J-Link Commander meine
.bin-Datei aufspielen und starten. Klasse. Die LED blinkt, jetzt kann es
weiter gehen :)
Vielen, vielen Dank :)
Jetzt wüsste ich nur noch gerne, wie es dazu kam. Bzw. wie ich das für's
zukünftige Arbeiten verhindern kann (das Olimexboard (H103) hat die
BOOT-pins leider nur als Löt-Jumper ausgeführt, also nicht gerade
praktisch, um die immer wieder zu verändern ;))
>> Jetzt wüsste ich nur noch gerne, wie es dazu kam.
Keine Ahnung, habe jedenfalls sowas in meinem gdb-Script stehen:
"monitor stm32x unlock 0" Vielleicht hilft's.
mfg
Generell besteht bei vielen ARM Cores das Problem, dass der Core mit
Reset den Kontakt zum JTAG/Debugger verliert und sofort losläuft. Der
muss dann erst wieder den Kontakt aufbauen. Wenn der Core sich selbst
lahmlegt bevor dies geschafft ist, dann gute Nacht. Ich las zwar, dass
die CM3 sich anders als die ARM7TDMI irgendwie ab Reset debuggen lassen
sollen, aber das ist wohl nicht universell bekannt und implementiert.
Aus dieser Situation kommt man nur mit Bootloader wieder raus, weil da
ab Reset nicht der Flash-Code losläuft, sondern eben der Bootloader.
ARMs ohne Bootloader kann man dann wegwerfen.
Jedenfalls führt diese Problematik dazu, dass Startup-Codes für ARMs
aller Art gerne irgendwelche Tricks vornedrin haben, die dem JTAG den
Zugang ermöglichen, bevor der Code Unfug stiften kann, wie
beispielsweise versehentlich den eigenen Takt oder die JTAG-Pins
abzuschalten. Ob Endlos-Schleife bei Crossworks oder (eleganter) eine
endliche Warteschleife, direkt nach dem Reset, vor jeder anderen
Initialisierung.
In der Errata-Liste des Cores - nicht der des STM32 - steht ein Bug
drin, mit dem sich der Core locken kann.
A. K. schrieb:
> Generell besteht bei vielen ARM Cores das Problem, dass der Core mit> Reset den Kontakt zum JTAG/Debugger verliert und sofort losläuft.
Das Problem ist eigentlich weniger im Core selbst zu finden, als in
der Art und Weise, wie die Reset Signale auf dem ASIC verdrahtet
sind (debug- und core-reset einfach mal verbunden).
> Ich las zwar, dass die CM3 sich anders als die ARM7TDMI irgendwie ab> Reset debuggen lassen sollen, aber das ist wohl nicht universell> bekannt und implementiert.
Der Mechanismus heißt vector catching und ist im Wesentlichen
identisch zu dem seit ARM9E-S implementierten Verfahren. Also nicht
gerade neu.
Generell gibt es aber bei Debug tools die Schwierigkeit einerseits
möglichst die gesamte Debug Funktionalität des Cores abzubilden und
gleichzeitig ein durch die Bank einheitliches Erscheinungsbild für
sämtliche unterstützten Prozessorfamilien und Hersteller zu
wahren. Selbst wenn man sich auf ARM beschränkt wird das sehr schnell
unübersichtlich.
Will man das haben, muss man sich schon bei den teureren tools (ARM
RVDS + RVI, Lauterbach Trace32, etc.) umschauen, deren
Anschaffungskosten dann aber ohne weiteres im oberen vierstelligen
Bereich liegen.
Zum Glück kann man beim Cortex-M3 fast alle Debug Register via Memory
Map erreichen und exotischere Funktionalität notfalls auch manuell
aktivieren.
> In der Errata-Liste des Cores - nicht der des STM32 - steht ein Bug> drin, mit dem sich der Core locken kann.
Meinst Du diesen: 463764? Das wäre aber sehr unwahrscheinlich den
erstens überhaupt und zweitens im Reset Handler zu treffen.
Übrigens: Im Cortex-M3 hat der Begriff lock-up eine spezielle
Bedeutung. Wir wissen nicht, ob Segger möglicherweise den Begriff
zufällig verwendet hat.
Gruß
Marcus
> Übrigens: Im Cortex-M3 hat der Begriff lock-up eine spezielle> Bedeutung. Wir wissen nicht, ob Segger möglicherweise den Begriff> zufällig verwendet hat.
Glaube ich eher nicht, die Kollegen werden sich dazu aber gerne nochmal
hier oder direkt im unserem Forum dazu melden.
Hi,
ich melde mich mich nochmal zu Wort ;) Ich dachte ja bisher, es hätte
geklappt. Aber es scheint so zu sein, dass ich den STM32 nur
programmieren kann (per "loadbin C:\temp\main.bin 0x20001000" im J-Link
Commander), wenn ich per Boot-Pins den Bootloader aktiviert habe.
Löte ich diese wieder zurück, so habe ich wieder das gleiche Problem wie
vorher.
Löte ich dann wieder auf Bootloader-Position funktioniert wieder alles,
ohne das ich sonst was geändert habe.
Wie kommt das? Ich möchte den ja irgendwann mal "ordentlich" nutzen,
also auch ohne JTAG und Bootloader angeschlossen...
Wenn du immer das gleiche Programm in kleineren Varianten reinlädst,
dann könnte es am immer gleichen Problem deines Programms liegen. ;-)
Mit Bootloader lässt er sich dann löschen, anschliessend auch ohne
Bootloader ins leere Flash laden. Aber danach ist Schluss, weil nun das
Programm nach jedem Reset den Core lahmlegt, noch bevor JTAG eine Chance
hat.
Hi,
an dem Programm kann es nicht liegen:
Ich lösche per Bootloader das gesamte Memory (Erase Memory 43BC FF00).
Direkt danach löte ich den Jumper um und bekomme dann die Fehlermeldung.
Gruß
Lasse
Das klang oben aber noch ganz anders:
"Jetzt die (super duper) gute Nachricht: Das Löschen des Devices per
Bootloader hat geholfen! Jetzt konnte ich per J-Link Commander meine
.bin-Datei aufspielen und starten. Klasse. Die LED blinkt, jetzt kann es
weiter gehen :)"
Das was du nun schreibst steht dazu im Widerspruch.
Hi,
sorry, dass das etwas verwirrend war :)
Es stimmt leider beides. Mein Vorgehen:
1.) Rumprobieren ohne Ahnung
2.) Irgendwann "core is locked-up" bekommen (vielleicht auch schon von
Anfang an, keine Ahnung :( )
3.) Bootpins setzen und Reset
4.) per Bootloader Flash löschen
5.) Reset (aber immer noch im Bootloadermodus)
6.) "Juhu, super duper: ich kann programmieren"
im J-Link Commander:
"loadbin c:\temp\main.bin 0x20001000
setpc 0x20001000
go"
=> die LED blinkt so wie sie soll
7.) Bootpins zurück setzen, im normalen Modus starten
8.) "Core is locked-up" wieder bekommen
9.) Bootloader gestartet
10.) Ich kann wieder programmieren
11.) per Bootloader Flash löschen
12.) Ich kann immer noch programmieren
13.) per Bootloader Flash löschen
14.) Bootpins zurücksetzen, im normalen Modus starten
15.) ich kann nicht mehr programmieren => "core is locked-up".
Danke für die Hilfe :)
Ich kann leider nicht direkt weiter helfen, habe aber einen unserer
J-Link Experten gebeten hier zu antworten, ich hoffe, das er heute noch
dazu kommt.
Gruß,
Til
Lasse S. schrieb:
>...> "loadbin c:\temp\main.bin 0x20001000> setpc 0x20001000> go">...
Ohne es je selbst ausprobiert zu haben...
Der genannte Adressbereich liegt im STM32F10x RAM. Es könnte sein, dass
der (nicht-)Code eines gelöschten Flash-Speichers, beim Start im
"normalen Modus" einen Lock-Up auslöst (den von Marcus Harnisch
07.02.2010 18:30 angesprochenen). 0xffffffff an erster Stelle im Flash
ist zumindest keine gute Idee für "Intial SP value". Habe grade nur das
STM32 Programming Manual zur Hand, man findet dort mit Suchbegriff "lock
up" eine Minierläuterung, mehr wird wohl im TRM von ARM stehen. Hatte
das Problem bis dato nicht, arbeite aber auch mit anderen Werkzeugen.
Man könnte ausprobieren, erstmal ein Minimalprogramm ins Flash (ab
0x08000000) zu laden. Nur Stack-Pointer Adresse, Spungadresse
Reset-Handler und im Reset-Handler nur eine Endlosschleife. Damit dürfte
der Core zumindest beim Start aus dem Flash in einem nutzlosen aber
zumindest definierten Zustand sein. Dannach ausprobieren, ob laden,
ausführen und debuggen von Programmen im RAM funktioniert.
Falls weiter mit Programmcode im RAM getestet werden soll: später auch
genau schauen, wie die Stackpointer gesetzt werden und die Vector-Table
Ursprungsadresse eingestellt wird. Kann man wahrscheinlich auch mit den
Programmen von Segger über ein Script machen (vor "go").
Hallo,
das würde ich sehr gerne ausprobieren.
Das (funktionierende) LED-Blinkprogramm kann ich momentan nur in das Ram
(also 0x20001000, wg. Bootloader sicherhalthalber n bisschen weiter
hinten) schreiben.
"loadbin c:\temp\main.bin 0x0800000" spuckt zwar keinen Fehler aus, aber
"mem 0x08000000 10" gibt nur 0xFF zurück.
Warum das mit dem J-Link Commander nicht funktioniert: keine Ahnung?
Mittels µVision kann ich aber in den Flash schreiben. Dort habe ich aber
noch kein Minimalbeispiel gefunden. Könntest du mir so eines geben? Die
Beispiele, die ich gefunden habe, waren entweder sehr umfangreich und
nicht für das Olimexboard gedacht, oder waren nicht kompilierbar...
Das Programming Manual von STM werd ich mir jetzt mal zu Gemüte führen.
Edit: Hier mal der Auszug aus dem PM:
> 2.4.4 Lockup> The processor enters a lockup state if a hard fault occurs when> executing the NMI or hard fault handlers. When the processor is> in lockup state it does not execute any instructions.> The processor remains in lockup state until either:> - It is reset> - An NMI occurs> If lockup state occurs from the NMI handler a subsequent NMI does not> cause the processor to leave lockup state.
Anscheinend kann also das 0xFF im Flash der Fehler sein, wenn ich das
richtig verstehe. Jetzt bräuchte ich nur noch n Minimalbeispiel, was ich
da reinladen kann. (Muss ja nichts anderes machen, als ne
while(1)-Schleife in der Main beinhalten und mit µVision funktionieren)
Gruß und weiterhin vielen Dank
Lasse
Lasse S. schrieb:
> Jetzt bräuchte ich nur noch n Minimalbeispiel, was ich> da reinladen kann. (Muss ja nichts anderes machen, als ne> while(1)-Schleife in der Main beinhalten und mit µVision funktionieren)
uVision Eval-Lizenzen habe ich derzeit keine mehr installiert. Grob aus
der Erinnerung relativ einfacher Weg (jemand anders weiss es sicher
besser): Projekt->Neu, Controller auswählen, Frage "Startup in Projekt
kopieren" -> ja, Startup-Datei öffnen (STM32*.s), Quellcode-Ansicht
(nicht "Wizard/Assistent"), nach Funktion ResetHandler suchen, dort
steht etwas in der Art LDR R0,=_main BX R0, das BX R0 durch B . (Be
Punkt) ersetzen, build, load to flash
Ok,
ihr werdet mich jetzt sicherlich alle schlagen wollen. Aber:
"Es funktioniert und ich habe nichts geändert."...
Keine Ahnung, was passiert ist, aber jetzt funktioniert es.
Ich hoffe nur, dass ich nicht nochmal in die "lockup"-Position gelange,
weil ich jetzt leider nicht weiß, was ich dagegen getan hab...
An dem gelöschten Flash kann es eigentlich nicht liegen, zumindest ließ
es sich nicht reproduzieren..
Wie ich sowas mag: Ein Fehler, der einfach auftritt, einfach weggeht und
nicht reproduzierbar ist.
Komisch. Bin gespannt, wie holprig mein weiterer Weg wird. stolper.
Euch allen vielen Dank für die Hilfe, habe einiges gelernt. Ich hoffe,
es geht jetzt besser voran, sonst weiß ich ja, wo ich mich melden muss.
Vielen Dank! :)
Gruß
Lasse
PS: Das mit dem Minimalbeispiel von Keil funktioniet so leider nicht, da
er über komische, fehlende Dinge meckert. Aber ich hab ein anderes
Beispiel genommen und dort einfach den kompletten Inhalt der main
gelöscht.
Hi,
ich dachte mir, ich sollte vielleicht etwas Licht ins Dunkle bringen,
bezüglich des Downloads ins Flash via J-Link commander:
>>"loadbin c:\temp\main.bin 0x0800000" spuckt zwar keinen Fehler aus, aber>>"mem 0x08000000 10" gibt nur 0xFF zurück.>>Warum das mit dem J-Link Commander nicht funktioniert: keine Ahnung?
Der J-Link DLL muss zuerst mitgeteilt werden, welches Device am J-Link
hängt, damit die memory map bekannt ist und somit auch, wo welcher
Speicher liegt.
Hier würde die entsprechende Befehlsabfolge für den J-Link Commander,
wie folgt lauten:
exec device = STM32F103RB
loadbin c:\temp\main.bin 0x0800000
r
g
"r" um Stack-Pointer sowie PC entsprechend zu initialisieren.
Eine Liste aller Devices, die unterstützt werden, findet ihr im UM08001,
6.4 Supported Devices (2. Spalte der Tabelle, Device IDs)
- Alex
Super!
Vielen Dank, das ist echt toller Support! :)
Jetzt läuft das Programm, sobald ich die Spannungsversorgung anschalte.
Toll :) freu
Jetzt muss ich nur noch selber Programme schreiben lernen, aber das hat
ja nichts mehr mit dem JLink zu tun ;)
Gruß
Lasse
Hallo zusammen.
hatte gerade ein ähnliches Problem mit dem J-Link in Verbindung mit dem
JTAG Isolator.
Fehlermeldung war u.A.
"TCK low - should be high - check Target".
Es hat geholfen die JTAG Frq von 10MHz auf 5MHz zu senken.
Außerdem musste man den J-Link erst auf permanente Spannungsversorgung
umprogrammieren (das steht z.G. im Inbetriebnahmeleitfaden".
vielleicht hilfts jemandem.
Gruß
Jedi
hallo
ich habe ausversehen die firmaware gelöscht, wann ich J-link mit PC
anschließe wird als unbeknntes Gerät erkannt,was kann ich jetzt machen?
danke
Thread beobachten
Seitenaufteilung abschalten