STM32 bleibt im mer beim "Reset_Handler" hängen

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

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?

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?

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

Ich habe nun nochmals auf 5.5.2 geupdatet.

Nun kann ich teilweise wieder Debuggen.
Zumindest bis zu dieser Stelle:

1

  //USART1

2

  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_6;    //TX1

3

  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;

4

  GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;

5

  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;

6

  GPIO_Init(GPIOB, &GPIO_InitStructure);

Wobei einige Zeilen zuvor bereits GPIOs ohne Probleme initialisiert 
wurden.

1

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 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:

1

GPIO_PinAFConfig(GPIOB, GPIO_PinSource6, GPIO_AF_0);

Das Programm lief auch einwandfrei.

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 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.

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

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.

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 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.

Problem scheint gelöst zu sein.

Danke!

Was war es denn?

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.