mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Cortex-M3 "Core is locked-up" (J-Link + Segger)


Autor: Lasse S. (cowz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Load "[...]\\Obj\\Gpio.AXF" 
JLink info:
-----------
DLL: V4.10i, compiled Jan 25 2010 14:43:57
Firmware: J-Link ARM V8 compiled Dec  1 2009 11:42:48
Hardware: V8.00
S/N : 268000075 
OEM : SEGGER-EDU 
Feature(s) : FlashBP 
---
* JLink Info: TotalIRLen = 9, IRPrint = 0x0011
* JLink Info: Found Cortex-M3 r1p1, Little endian.
* JLink Info: TPIU fitted.
* JLink Info:   FPUnit: 6 code (BP) slots and 2 literal slots
* JLink Info: TotalIRLen = 9, IRPrint = 0x0011
* JLink Info: Found Cortex-M3 r1p1, Little endian.
* JLink Info: TPIU fitted.
* JLink Info:   FPUnit: 6 code (BP) slots and 2 literal slots

Target info:
------------
Device: STM32F103VB
VTarget = 3.293V
State of Pins: 
TCK: 1, TDI: 0, TDO: 1, TMS: 0, TRES: 1, TRST: 1
* JLink Info: TotalIRLen = 9, IRPrint = 0x0011
* JLink Info: Found Cortex-M3 r1p1, Little endian.
* JLink Info: TPIU fitted.
* JLink Info:   FPUnit: 6 code (BP) slots and 2 literal slots
Hardware-Breakpoints: 6
Software-Breakpoints: 2048
Watchpoints:        4
JTAG speed: 3000 kHz
---
* JLink Info: TotalIRLen = 9, IRPrint = 0x0011
* JLink Info: Found Cortex-M3 r1p1, Little endian.
* JLink Info: TPIU fitted.
* JLink Info:   FPUnit: 6 code (BP) slots and 2 literal slots
* JLink Info: Core is locked-up!
* JLink Info: CPU halted
Programming Failed!

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schraub auch mal die JTAG-Taktfrequenz runter.

Autor: Lasse S. (cowz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;))

Autor: nicht_eingeloggt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: SEGGER - Til Stork (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ü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.

Autor: Lasse S. (cowz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Lasse S. (cowz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Random ... (thorstendb) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

kannste jetzt mit uVision und dem Cortex-M3 JLink Treiber das Board 
programmieren?


VG,
/r.

Autor: Lasse S. (cowz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: SEGGER - Til Stork (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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").

Autor: Lasse S. (cowz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lasse S. (cowz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: SEGGER - Alex G. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lasse S. (cowz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jedi82 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: j-link (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.