mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik STM32 bleibt im mer beim "Reset_Handler" hängen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Ich versuche mein Programm mit Atollic True Studio 5.5.0 zu debuggen 
bzw. zu complirieren.

Compilieren klappt soweit. Bis vor kurzem funktionierte auch das 
Debuggen noch ohne Probleme. Seit einer Änderung der Initialisierung 
einer Variable von 0 auf 0x25, funktioniert das Debuggen nicht mehr.

Auch ein zurückändern brachte keine Abhilfe.


Nach dem starten der Debugsession, bleibt das Programm im Startup script 
hängen:

  .section .text.Reset_Handler
  .weak Reset_Handler
  .type Reset_Handler, %function
Reset_Handler:
--->  ldr   r0, =_estack
  mov   sp, r0          /* set stack pointer */

/* Copy the data segment initializers from flash to SRAM */
  movs r1, #0
  b LoopCopyDataInit


Controller: STM32F030K6T6
Speicher: 32kByte Flash
Ram: 4kByte

Die Ausgabe aus der Console nach dem Compilieren ist:
Print size information
   text     data      bss      dec      hex  filename
  22672      148      284    23104     5a40  iMS.elf
Print size information done
Generate build reports done


Dynamische Speicheralloziierung habe ich keine.
Kann es sein, dass ich den Speicher überlaufen lasse?

Danke schonmal

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Zeigt denn _estack auch auf das Ende des RAM?

von Holger K. (holgerkraehe)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hp-freund schrieb:
> Zeigt denn _estack auch auf das Ende des RAM?

Gute Frage

Das kann ich nicht beurteilen.
Das StartupFile wurde automatisch hineinkopiert.

Anbei das gesamte File

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Klingt als wäre dein Controller permanent im Reset, also zB nRST ständig 
auf 0. Mit der ldr Instruktion hat das glaube ich nichts zu tun.

von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> hp-freund schrieb:
>> Zeigt denn _estack auch auf das Ende des RAM?
>
> Gute Frage
>
> Das kann ich nicht beurteilen.
> Das StartupFile wurde automatisch hineinkopiert.
>
> Anbei das gesamte File

Sollte estack nicht im Linkerscript definiert sein?

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Klingt als wäre dein Controller permanent im Reset, also zB nRST ständig

Ist er nicht.
Weil sobald ich die Debugsession beende, läuft das alte Programm 
weiterhin.
Wenn ich den Controller mittels ST Utility lösche und dann erneut 
Debugge, befindet sich auch wieder ein Programm darauf.

Cyblord -. schrieb:
> Sollte estack nicht im Linkerscript definiert sein?

Vermutlich schon.
Sollte sich dieses in meinem Projektordner befinden?

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Sollte estack nicht im Linkerscript definiert sein?

Genau.

/* Highest address of the user mode stack */
_estack = 0x20001000;    /* end of RAM */

STM32F030K6Tx_FLASH.ld sollte im Projektverzeichnis sein.

Müsste der linker aber meckern wenn die nicht da ist.

von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:

>
> Vermutlich schon.
> Sollte sich dieses in meinem Projektordner befinden?

Ich weiß nicht wie Atollic die Dateien organsiert. Aber vermutlich 
schon. Endung .ld

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mit CubeMX erstelltes Truestudio Projekt leget eine STM32F030K6_FLASH.ld
in das Projektverzeichnis.

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Es kann aber natürlich auch sein das sich der Debuger verlaufen hat ;)

von Holger K. (holgerkraehe)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe nun nochmals auf 5.5.2 geupdatet.

Nun kann ich teilweise wieder Debuggen.
Zumindest bis zu dieser Stelle:
  //USART1
  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_6;    //TX1
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
  GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
  GPIO_Init(GPIOB, &GPIO_InitStructure);

Wobei einige Zeilen zuvor bereits GPIOs ohne Probleme initialisiert 
wurden.
GPIO_Init(GPIOB, &GPIO_InitStructure);

Ab hier geht er nicht mehr weiter.
Und lässt sich auch nicht mehr pausieren.


Anbei noch das Linkerskript.

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Debug Frequenz zu hoch?

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
B6 ist ja der alternative TX1, fehlt da nicht etwas in der Art:

GPIO_InitStruct.GPIO_Alternate = GPIO_AF0_USART1;

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
hp-freund schrieb:
> Debug Frequenz zu hoch?

Ich konnte es bereits erfolgreich Debuggen, stundenlang.
Seit dem anpassen der Variable ging es nicht mehr.

hp-freund schrieb:
> B6 ist ja der alternative TX1, fehlt da nicht etwas in der Art:

Ist alles vorhanden:
GPIO_PinAFConfig(GPIOB, GPIO_PinSource6, GPIO_AF_0);

Das Programm lief auch einwandfrei.

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Seit dem anpassen der Variable ging es nicht mehr.

Nun verrate uns doch mal was das für eine magische Variable ist.

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
hp-freund schrieb:
> Nun verrate uns doch mal was das für eine magische Variable ist.

uint8_t deviceAddress = 0;

Diese habe ich mal kurzzeitig auf 0x25 gehabt.
Kann mir nicht vorstellen, dass es damit was zu tun hat.


Das Programm läuft ohne Debugger problemlos.
Wenn ich es mit dem Debugger laufen lasse, dann macht es plötzlich einen 
Break und springt an eine willkürliche stelle im c-code wobei die Stelle 
jedesmal gleich ist. Früher hatte ich dort mal einen Breakpoint gehabt.

Einen Breakpoint habe ich aktuell jedoch nicht. Also damit meine ich 
überhaupt keinen. Auch keinen deaktivierten.

: Bearbeitet durch User
von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich kenne Atollic nicht,  würde aber ein neues Projekt anlegen und die 
vorhandenen Dateien einfügen.
Wer weiß wo und wie die Einstellungen überall gespeichert werden.

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
hp-freund schrieb:
> Ich kenne Atollic nicht,  würde aber ein neues Projekt anlegen und
> die
> vorhandenen Dateien einfügen.
> Wer weiß wo und wie die Einstellungen überall gespeichert werden.

Hab ich nun gemacht

Stoppt wieder an genau der selben Stelle im Code.
Ohne das ich dort einen Breakpoint habe.

von Stefan K. (stefan64)


Bewertung
0 lesenswert
nicht lesenswert
Wenn Du Deine Variable mit Null initialisiert, dann legt der Linker sie 
in den Datenbereich, der nicht initialisiert, aber vor dem Start 
ausgenullt wird.
Wenn Du Deine Variable mit 25 initialisierst, dann legt der Linker sie 
in den Block,dessen Init-Werte beim Startup aus dem Flash ins RAM 
kopiert werden.
Das Problem liegt am Startup-Code, eventuell ist das .Data Segment 
falsch angegeben.

Siehe auch folgenden Thread:
Beitrag "Woher kommen die Segmentnamen ".text", ".bss" und ".data" ?"

und:
https://en.wikipedia.org/wiki/Data_segment

von Horst (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Welcher Debugger ist es denn? JLink hat in letzter Zeit öfters 
unerklärliche Probleme mit zB STM32F0. Der 3 Euro China Klon des ST 
Links hingegegen ging ohne Probleme.

von hp-freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan K. schrieb:
> Das Problem liegt am Startup-Code, eventuell ist das .Data Segment
> falsch angegeben.

Das kann doch beim neu anlegen eines Projektes eigentlich nur durch 
Auswahl des falschen µC passieren, oder?

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Stefan K. schrieb:
> Das Problem liegt am Startup-Code, eventuell ist das .Data Segment
> falsch angegeben.

Danke, werde ich mir gleich anschauen.

Ich habe noch eine neue Spur...

Der breakpoint befindet sich immer an der Adresse 0x80037e2
Aktuell befindet sich dort etwas aus dem Timer Interrupt.

Wenn ich nun die Optimierung (welche bisher deaktiviert war) aktiviere, 
dann macht er weiterhin einen break bei 0x80037e2 nur dann liegt dieser 
in der Funktion pow() welche aus der math.h stammt für welche ich keine 
Sourcen habe.

Wenn ich unter breakpoints, alle aktiven breakpoints ansehe, finde ich 
diesen nicht. bzw. ich habe überhaupt keine gesetzt.

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Horst schrieb:
> Welcher Debugger ist es denn?

Offizieller ST-Link V2 Debugger.
Hat ja bis vor ein paar Stunden noch ohne Probleme funktioniert.

hp-freund schrieb:
> Das kann doch beim neu anlegen eines Projektes eigentlich nur durch
> Auswahl des falschen µC passieren, oder?

Controller ist definitiv der richtige.

von Jay (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

sicher, dass er an die Stelle 'springt' und dann hängt. Kann es 
vielleicht sein, dass er den Code normal abarbeitet einfach an der 
Stelle stehen bleibt?

Ich habe bei Eclipse(darauf basiert afaik Atollic) manchmal das Problem, 
dass ein Breakpoint in der IDE gelöscht wird, der Debugger das aber 
nicht mitbekommt. Bei mir hilft es dann "Remove All" im 
Breakpoint-Kontextmenü auszuwählen. Anschliessend läuft das Programm 
durch den ehemaligen Breakpoint durch.

Alternativ Zielhardware und Debugger mal stromlos machen?
("Have you tried turning it off and on again?")

CU,
Jay

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Jay schrieb:
> Alternativ Zielhardware und Debugger mal stromlos machen?
> ("Have you tried turning it off and on again?")

Hab ich gemacht

Jay schrieb:
> Bei mir hilft es dann "Remove All" im
> Breakpoint-Kontextmenü auszuwählen.

Werde ich gleich versuchen.

Jay schrieb:
> Ich habe bei Eclipse(darauf basiert afaik Atollic) manchmal das Problem,
> dass ein Breakpoint in der IDE gelöscht wird, der Debugger das aber
> nicht mitbekommt.

Ist vermutlich genau das.

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Problem scheint gelöst zu sein.

Danke!

von Stefan K. (stefan64)


Bewertung
0 lesenswert
nicht lesenswert
Was war es denn?

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Stefan K. schrieb:
> Was war es denn?

Nicht deaktivierte, alte Breakpoints.

Während dem Debuggen under Run->Disable all Breakpoints

Kann das Problem gelöst werden.

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.