mikrocontroller.net

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


Autor: Holger K. (holgerkraehe)
Datum:

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

Autor: hp-freund (Gast)
Datum:

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

Autor: Holger K. (holgerkraehe)
Datum:
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

Autor: Dr. Sommer (Gast)
Datum:

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.

Autor: Cyblord -. (cyblord)
Datum:

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?

Autor: Holger K. (holgerkraehe)
Datum:

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?

Autor: hp-freund (Gast)
Datum:

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.

Autor: Cyblord -. (cyblord)
Datum:

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

Autor: hp-freund (Gast)
Datum:

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

Autor: hp-freund (Gast)
Datum:

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

Autor: Holger K. (holgerkraehe)
Datum:
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.

Autor: hp-freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Debug Frequenz zu hoch?

Autor: hp-freund (Gast)
Datum:

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;

Autor: Holger K. (holgerkraehe)
Datum:

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.

Autor: hp-freund (Gast)
Datum:

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.

Autor: Holger K. (holgerkraehe)
Datum:

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
Autor: hp-freund (Gast)
Datum:

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.

Autor: Holger K. (holgerkraehe)
Datum:

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.

Autor: Stefan K. (stefan64)
Datum:

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

Autor: Horst (Gast)
Datum:

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.

Autor: hp-freund (Gast)
Datum:

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?

Autor: Holger K. (holgerkraehe)
Datum:

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.

Autor: Holger K. (holgerkraehe)
Datum:

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.

Autor: Jay (Gast)
Datum:

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

Autor: Holger K. (holgerkraehe)
Datum:

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.

Autor: Holger K. (holgerkraehe)
Datum:

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

Danke!

Autor: Stefan K. (stefan64)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was war es denn?

Autor: Holger K. (holgerkraehe)
Datum:

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.