STM32 bleibt im mer beim "Reset_Handler" hängen

[Holger K. (holgerkraehe)]

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

[hp-freund (Gast)]

Zeigt denn _estack auch auf das Ende des RAM?

[Holger K. (holgerkraehe)]

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

[Dr. Sommer (Gast)]

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.

[Cyblord -. (cyblord)]

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?

[Holger K. (holgerkraehe)]

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?

[hp-freund (Gast)]

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.

[Cyblord -. (cyblord)]

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

[hp-freund (Gast)]

Mit CubeMX erstelltes Truestudio Projekt leget eine STM32F030K6_FLASH.ld
in das Projektverzeichnis.

[hp-freund (Gast)]

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

[Holger K. (holgerkraehe)]

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.

[hp-freund (Gast)]

Debug Frequenz zu hoch?

[hp-freund (Gast)]

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

GPIO_InitStruct.GPIO_Alternate = GPIO_AF0_USART1;

[Holger K. (holgerkraehe)]

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.

[hp-freund (Gast)]

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.

[Holger K. (holgerkraehe)]

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.

[hp-freund (Gast)]

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.

[Holger K. (holgerkraehe)]

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.

[Stefan K. (stefan64)]

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

[Horst (Gast)]

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.

[hp-freund (Gast)]

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?

[Holger K. (holgerkraehe)]

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.

[Holger K. (holgerkraehe)]

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.

[Jay (Gast)]

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

[Holger K. (holgerkraehe)]

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.

[Holger K. (holgerkraehe)]

Problem scheint gelöst zu sein.

Danke!

[Stefan K. (stefan64)]

Was war es denn?

[Holger K. (holgerkraehe)]

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.