Hallo, ich habe ein NUCLEO-L412KB Board, das ich mit Segger-Software debugge. Da man den Segger-Debugger nicht ans Board anschließen kann (SWD ist nicht auf Pins geführt) habe ich den auf dem Board integrieren ST-Link auf dem Board als J-Link konvertiert (Programm STLinkReflash.exe). Funktioniert auch problemlos. Wenn ich aber den Debugger beende, läuft das Programm nicht los, auch wenn ich (USB-)Netzreset mache oder die Reset-Taste drücke. Das selbe geht auch nicht, wenn ich "Restore ST-Link" mache und den Originalzustand des integrierten ST-Links erzeuge. Habe auch schon den integrierten ST-Link auf V2.J35.M26 upgedated. Bringt alles nichts. Warum läuft der Mikrocontroller nicht los? Gruß Martin
Gast
#6058727
Martin R. schrieb: > Warum läuft der Mikrocontroller nicht los? Zwei Möglichkeiten fallen mir da ein: a) Er bekommt keinen Takt -> Auf R/C Oszillator umstellen b) Der Programmieradapter zieht die Reset Leitung auf Low -> Leitung unterbrechen.
Stefan F. schrieb: > a) Er bekommt keinen Takt -> Auf R/C Oszillator umstellen Läuft schon immer mit RC-Oszillator. > b) Der Programmieradapter zieht die Reset Leitung auf Low -> Leitung > unterbrechen. Reset ist High. Ich vermute der Mikrocontroller wird per Befehl über die SWD-Schnittstelle im Wartemodus gehalten.
Gast
#6058887
oder wenn semihosting aktiviert ist und etwas ausgegeben wird hängt der µC auch.
Johannes S. schrieb: > oder wenn semihosting aktiviert ist und etwas ausgegeben wird hängt der > µC auch. was kann man dagegen machen?
Martin R. schrieb: >> oder wenn semihosting aktiviert Martin R. schrieb: > was kann man dagegen machen? Semihosting in den Linker Optionen abstellen.
Gast
#6058900
Gucken ob das aktiv ist, wenn man eine IDE verwendet ist es evtl. nur ein Häkchen was mal unbedacht gesetzt wurde.
Gast
#6059013
Wenn man den ST-Link nicht braucht, z.B. weil das Board sowieso standalone laufen soll, einfach den RST vom ST-Link auf Low ziehen. Das ist bei manchen sogar schon fuer eine optionale Loetbruecke vorbereitet. (Pin 8 vom STM32F103) Ob da ein JLinklight oder die originale Firmware drauf ist, ist logischerweise egal...
Gast
#6059015
P.S. Nebenwirkungen: Der Controller bekommt vom ST-Link keinen Takt mehr. Also Quarz bestuecken und Bruecke zum ST-Link auftrennen. HSE-Bypass darf dann natuerlich nicht eingeschaltet werden. Der interne Taktgenerator ist natuerlich nicht betroffen. Der u.U. vorhandene serielle Adapter vom ST-Link ruht auch. Die uebrigen Hinweise (Semihosting, ...) auch beachten.
Semihosting: es gibt bei Segger keine entsprechende Option zum Auswählen RST vom ST-Link auf Low ziehen: brachte nichts USB nicht stecken und 5V an VIN einspeisen: brachte nichts USB nicht stecken und 3,3V an VDD einspeisen (Jumper JP1 zum Spannungsregler offen): brachte nichts.
Gast
#6059312
Hast du am Linkerskript rumgespielt? Das ist mir mal passiert, als ich einen Bootloader auf einem ARM Cortex installiert habe. Der Code wurde hinter dem Bootloader ins Flash geschrieben. Wenn kein Bootloader drauf war, lief der Controller nur, wenn der Debugger die Ausführung an der richtigen Adresse gestartet hat..
Gast
#6059347
Möchtest Du ein Blinky probieren? HSI RC, 1MHz am MCO.
pegel schrieb: > Möchtest Du ein Blinky probieren? Gerne, aber ich habe nun das Problem, daß der Cube-Programmer nun nicht mehr geht, um das HEX-File drauf zu schieben. Er kann keine Verbindung zum Board aufbauen: 13:41:54 : ST-LINK error (DEV_USB_COMM_ERR) 13:41:54 : Error: Problem occured while trying to connect Im Gerätemanager wird jedoch nach dem Stecken COM7 erkannt.
moep schrieb: > Hast du am Linkerskript rumgespielt? Nein, zumindest Nicht bewußt.
Gast
#6059394
Martin R. schrieb: > daß der Cube-Programmer nun nicht > mehr geht Hast Du das Board mal vom USB getrennt? Danach solltest Du vielleicht ein ST-Link Firmware Update probieren.
Cube-Programmer geht nun wieder. Hatte sich komplett aufgehangen. Das Blinky-Hex-File von "pegel" geht, wenn ich aber mein HEX-File drauf spiele, sollte es eigentlich auch blinken. Tut sich aber nichts.
Hab mal das Projektfile vom Segger als Textfile angehängt. Vielleicht fällt jemandem eine falsche Einstellung auf. Ich habe den Cube für das Projekt verwendet und Toolchain MDK-ARM V5 verwendet. Das damit erzeugte MDK-Projekt kann man dann im Segger importieren. Ob da was schief gelaufen ist? Ich arbeite erst seit diesem Projekt mit dem neusten Cube. Was mir auffiel, daß die C-Dateien nach dem Import (main.c) dann im Segger nicht erschienen sind, mußte ich dann per Hand dazu fügen.
Gast
#6059459
Von Segger habe ich keine Ahnung, aber Du kannst die CubeMX Projekt Datei anhängen. (.ioc)
anbei die Cube-Datei.
Gast
#6059484
Merkwürdig. Deine ioc meint, dass die L4 v1.14.0 Lib oder eine Abhängigkeit fehlt. Ist aber bei mir definitiv vorhanden. Habe die .hex damit erstellt. Vielleicht kann das noch jemand anders testen bevor ich etwas bei mir verstelle?
Gast
#6059503
Ob das vielleicht mit der CubeMX Version zu tun hat? Du hast die 5.3.0, ich die aktuelle 5.4.0. Ich kenne eigentlich eine andere Meldung, wenn die .ioc aus einer anderen Version kam, aber man weiss ja nie....
pegel schrieb: > Du hast die 5.3.0, ich die aktuelle 5.4.0. Ich habe nun Cube auf 5.4.0 upgedated und das alte Projekt geöffnet. Hat soweit plausible Einstellungen angezeigt. Aber beim Erzeugen des Codes bleibt das Programm hängen (siehe Anhang).
Angehängte Dateien:
-
Cube_neu.png
(12 KB)
Gast
#6059587
Hat er es noch geschafft? Wie gesagt, habe keinen Schimmer von Segger. Kann das ein Makefile Projekt importieren? Das kann CubeMX auch erstellen. Was meint Segger dazu?
Nein Cube bleibt generell hängen, auch mit neu angelegtem Projekt. Habe auch Java neu installiert, brachte nichts. Import-Möglichkeiten siehe Anhang. Segger an sich ist super, vor allem als Privatperson kostenlos! Und Debug-Box für Privatanwendungen kostet nur 60 €. Bei Segger bekommt man keinen aktiven Support als Privatperson. Da hat man nur Möglichkeiten über Forum. Und zum Thema Probleme ST-Link als J-Link mißbrauchen wollen sie keinen Support geben. Wollen ja schließlich ihre Box verkaufen...
Angehängte Dateien:
-
Import_Segger.png
(3 KB)
Gast
#6059629
Kann man, nachdem man in Segger schon gearbeitet hat, noch einmal Änderungen in CubeMX vornehmen? Falls nicht, CubeIDE kann das ;)
pegel schrieb: > ann man, nachdem man in Segger schon gearbeitet hat, noch einmal > Änderungen in CubeMX vornehmen? > Falls nicht, CubeIDE kann das ;) Ja, das geht problemlos. Wenn man vom Cube auf Segger umschaltet fragt er, ob man die extern geänderten Dateien verwenden will.
Gast
#6059933
Dann ist gut. Bleibt nur die Frage, ob CubeMX nicht korrekt exportiert, oder Segger nicht korrekt importiert. Läuft denn das neue CubeMX jetzt richtig?